gestion mémoire

drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkwu1i4qc6.fsf@fgeorges.org>...

kanze@gabi-soft.fr writes:

Ils en parlent de l'implémentation à templates. La technique est
bien plus ancienne que les templates (j'en ai entendu parler déjà en
1992, ou quelque part par là), et marche aussi bien avec des
fonctions virtuelles. En fait, j'ai fait un benchmark il y a cinq ou
six ans, avec Sun CC 4.2, et curieusement, c'était la version avec
fonctions virtuelles qui était la plus rapide.

Tu as deux codes équivalents, l'un utilisant des modèles, et l'autre
les mécanismes virtuels. Et le second est le plus rapide.

Oui.

C'est bien cela ? Cela me paraît étrange.

Que les méchanismes virtuels soient plus rapide m'a étonné aussi. Je me
serais attendu à exactement la même vitesse dans les deux cas. En fait,
je me serais attendu à exactement le même code généré dans les deux cas.

N'oublie pas que dans le cas en question, les fonctions virtuelles ne
sont appelées que sur des objets temporaires, dont le compilateur
connaît le type exact. Et que toutes les fonctions en question était
inline.

Te souviens-tu d'où venait la différence de temps ?

Je ne l'ai jamais su exactement. Il faut dire que le processeur (Sun
Sparc) a parfois des réactions bizarres où la performance change
notablement selon la taille des objets, mais je n'ai vu le cas que quand
les objets étaient dans une fonction plus haute dans la pile des appels,
et non dans la fonction critique même. Je sais aussi que dans la passée,
j'ai vu des compilateurs qui utilisaient le temps passé dans le
compilateur pour limiter jusqu'où ils allaient dans l'optimisation. En
gros, chaque passe d'optimisation réorganise le code, et le code
réorganisé peut reveler de nouvelles optimisations. Et le compilateur
n'acceptait de commencer une nouvelle passe que si le temps passé
jusqu'alors n'était pas trop élevé. Alors, le fait que le code templaté
coûte plus cher à compiler pourrait faire qu'on passe moins de temps
dans l'optimisateur. Mais c'est très, très vieux, ça, et je ne crois pas
que c'était le cas du compilateur en question (Sun CC 4.2).
Éventuellement, c'était dû à une limitation sur la mémoire utilisée,
mais là aussi, je ne sais pas au juste.

A priori, les templates sont beaucoup plus récents que les fonctions
virtuelles, et donc, la technologie des compilateurs en ce qui les
concerne est moins mature. Mais étand donné qu'une fois expansionné, un
template ne diffère en rien d'une fonction ou d'une classe classique, je
ne vois pas comment cette manque de maturité pourrait jouer sur
l'optimisation. (C'est certain, en revanche, que tu avais plus de chance
de tomber sur une erreur dans le compilateur avec des templates qu'avec
des fonctions virtuelles.)

Enfin, j'avoue que le résultat m'avais beaucoup étonné, à moi aussi.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr writes:

Éventuellement, c'était dû à une limitation sur la mémoire utilisée,
mais là aussi, je ne sais pas au juste.

Mouais. Comme tu le dis, le code généré par l'instantiation des
modèles devrait être identique, et l'aspect dynamique ne devrait pas
intervenir. Je vois mal où une différence peut intervenir, et a
fortiori sur la mémoire utilisée.

Veux-tu dire que le compilateur pourrait utiliser une mémoire
différente (différente à quel niveau ?) pour les deux sortes
d'objets ?

--drkm

drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkbrit72kz.fsf@fgeorges.org>...

kanze@gabi-soft.fr writes:

Éventuellement, c'était dû à une limitation sur la mémoire utilisée,
mais là aussi, je ne sais pas au juste.

Mouais. Comme tu le dis, le code généré par l'instantiation des
modèles devrait être identique, et l'aspect dynamique ne devrait pas
intervenir. Je vois mal où une différence peut intervenir, et a
fortiori sur la mémoire utilisée.

L'expansion des templates utilise de la mémoire. A priori, je
m'attendrais à ce que cette expansion soit finie, et la mémoire libérée,
avant de commencer l'optimisation, mais ce n'est pas moi qui a écrit le
compilateur. Il y a peut être des raisons pour retenir cette mémoire.

N'oublie pas que mes essais ont eu lieu à une autre époque. La machine
en question n'avait que 48 Mo de mémoire réele, et environ 100 Mo de
mémoire virtuelle. Et arrêter l'optimisation quand un malloc renvoie
NULL me semble un choix raisonnable.

Veux-tu dire que le compilateur pourrait utiliser une mémoire
différente (différente à quel niveau ?) pour les deux sortes
d'objets ?

Le compilateur retient en tout cas plus d'information en cas des
templates ; régarde ce qu'il te sort en cas d'une erreur. Mais s'il n'y
avait que ça, j'imagine que la différence serait minime.

Je suis assez sûr que la compilation brute des templates nécessite plus
de mémoire que la compilation des fonctions non templatées -- la
présence des templates augment de façon importante le nombre de
fonctions à considérer en cas de résolution d'un surcharge, par
exemple. Logiquement, je m'attendrais à ce que cette mémoire soit déjà
libérée lors du commencement de l'optimisation, mais je ne suis pas
sûr. Et libérée ou non, elle pourrait augmenter la fragmentation.

Mais tout ça, c'est de la spéculation. Je sais ce que j'ai mésure, mais
je ne sais pas vraiment plus. Je me rappelle des mésures simplement
parce qu'elles m'ont étonnées. Vue que je les avais faits un peu comme
ça, à côté de mon activité professionnelle, et qu'elles n'avaient pas
d'importance pour mon activité professionnelle, je n'ai pas cherché plus
loin.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bonjour a tous,

Je n'ai pas ecrit de francais depuis plus de quinze ans.
Mes excuses les plus Belges pour les fotes. (Ah, et mon
clavier n'a pas d'accents faciles. ;-)

kanze@gabi-soft.fr wrote in message news:<d6652001.0407050152.6e2fb044@posting.google.com>...

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<cc4ctg$l2f$1@news-reader2.wanadoo.fr>...

drkm wrote:

Porte-t-elle un nom ?

La technique basee sur les templates s'apelle "expression
templates". La version dynamique (non-template) tombe
dans la grande categorie "lazy evaluation" (evaluation
paresseuse?).

À vrai dire, pas que je sache. Mais c'est un problème que je n'ai suivi
que de loin, étant donné qu'il a peu d'application pratique dans les
domaines où je travaille.

J'ai jeté un coup d'oeil au tiny_vector de Blitz, mais cela est
plutôt ardu pour découvrir une telle technique. Peut-être as-tu
l'une ou l'autre référence ?

L'excellent "C++ template, the complete guide " de Josuttis et
Vandevoorde en parle.

Merci ;-)

Ils en parlent de l'implémentation à templates. La technique est bien
plus ancienne que les templates (j'en ai entendu parler déjà en 1992, ou
quelque part par là), et marche aussi bien avec des fonctions
virtuelles.

Oui: La technique dynamique fut utilise ici et la vers la fins des
annees '80. La premiere implementation semi-populaire etait
(je pense) NewMat par Robert Davies. La premiere version de
NewMat date de 1991 et je pense que Robert Davies la revise
de temps en temps. Voir
http://www.robertnz.net/nm_intro.htm

En fait, j'ai fait un benchmark il y a cinq ou six ans, avec
Sun CC 4.2, et curieusement, c'était la version avec fonctions
virtuelles qui était la plus rapide.

Les "expression templates" dependent fortement de la qualite de
l'expansion "en ligne" (inline expansion) et malheureusement ca
n'etait pas un point fort de Sun CC 4.x. D'autre part, l'efficacite
des implementation dynamique (telles que NewMat) est assez
bonne si le nombre d'operations numerique est relativement
grande (disons dans l'ordre de 1000 elements). Je m'attendrai
quand-meme a ce que pour des petits vecteurs (< 10 elements)
un implementation moyenne des expression templates soit plus
rapide qu'une bonne implementation dynamique.

Cela dit (et cela va peut-etre de soi), la technique des "expression
templates" a des limites semantiques comparee aux techniques
dynamiques. Par example, si A, B, et C sont des matrices plus
grandes que 1x1, les expression templates ne peuvent generalement
addresser les expressions de formes
A = B*C;
ou
A = A*C;

a cause de problemes d'alias. Let techniques dynamique, d'un
autre cote, peuvent faire une analyse au temps d'execution pour
void que
A = B*C;
ne necessite pas de (grande) memoire temporaire alors que
A = A*C;
a besoin d'une memoire temporaire dont la taille est une
fonction des taille de A et/ou C.

David

kanze@gabi-soft.fr wrote in message <d6652001.0407062357.fefc5e2@posting.google.com>:

drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkbrit72kz.fsf@fgeorges.org>...

kanze@gabi-soft.fr writes:

L'expansion des templates utilise de la mémoire. A priori, je
m'attendrais à ce que cette expansion soit finie, et la mémoire libérée,
avant de commencer l'optimisation, mais ce n'est pas moi qui a écrit le
compilateur. Il y a peut être des raisons pour retenir cette mémoire.

Ok. Tu parles de la mémoire utilisée lors de la compilation. Je
n'avais pas compris, et pensais que tu parlais de la mémoire à
l'exécution. Alors ok, je comprend.

N'oublie pas que mes essais ont eu lieu à une autre époque. La machine
en question n'avait que 48 Mo de mémoire réele, et environ 100 Mo de
mémoire virtuelle.

Une autre époque ? Mais, c'est mon époque à moi, ça. Avec mon bon
vieux K6 400, 64 Mo :-).

Et arrêter l'optimisation quand un malloc renvoie
NULL me semble un choix raisonnable.

Certainement.

[...]

--drkm

Daveed Vandevoorde wrote in message <52f2f9cd.0407070820.79ddd0d5@posting.google.com>

Bonjour a tous,

Je n'ai pas ecrit de francais depuis plus de quinze ans.
Mes excuses les plus Belges pour les fotes. (Ah, et mon
clavier n'a pas d'accents faciles. ;-)

Je schrijft als een Franstalige ;-)

La technique basee sur les templates s'apelle "expression
templates". La version dynamique (non-template) tombe
dans la grande categorie "lazy evaluation" (evaluation
paresseuse?).

Merci.

Si je peux entrevoir quelques détails, je n'arrive pas à imaginer
exactement l'ensemble. Quelqu'un a-t-il un exemple simple mais
complet ?

--drkm

google@vandevoorde.com (Daveed Vandevoorde) writes:

| Bonjour a tous,

Salut !

| Je n'ai pas ecrit de francais depuis plus de quinze ans.
| Mes excuses les plus Belges pour les fotes. (Ah, et mon
| clavier n'a pas d'accents faciles. ;-)

Ton clavier s'est trompé et a tapé "fr." devant compl.lang.c++ et
viré ".moderated" à l'insue de ton plein gré ? ;-)

-- Gaby

darkman_spam@yahoo.fr (drkm) wrote in message news:<8b283176.0407071735.362bdd8a@posting.google.com>...

Daveed Vandevoorde wrote in message <52f2f9cd.0407070820.79ddd0d5@posting.google.com>

Bonjour a tous,

Je n'ai pas ecrit de francais depuis plus de quinze ans.
Mes excuses les plus Belges pour les fotes. (Ah, et mon
clavier n'a pas d'accents faciles. ;-)

Je schrijft als een Franstalige ;-)

Maar ik ben in feite oorspronkelijk Franstalig (dwz.,
m'n moedertaal is Frans niettegenstaande m'n
familienaam).

La technique basee sur les templates s'apelle "expression
templates". La version dynamique (non-template) tombe
dans la grande categorie "lazy evaluation" (evaluation
paresseuse?).

Merci.

Si je peux entrevoir quelques détails, je n'arrive pas à imaginer
exactement l'ensemble. Quelqu'un a-t-il un exemple simple mais
complet ?

Je n'en ai pas la tout de suite. L'idee general est que
les operateur cree des objets representant l'operation
et que l'operator= accepte ces objets et les evaluent.

Pour les "expression template" chaque objet a un operator[]
en-ligne plus ou moins comme ceci:

template<typename T, typename A, typename B>
struct Somme {
// A & B sont soit une espece de vecteur concret,
// ou un type qui represente une operation vectorielle
// (comme Somme<...>).
Somme(A const &ra, B const &rb): a(ra), b(rb) {}
T operator[](ptrdiff_t i) { return a[i]+b[i]; }
A a;
B b;
};

Note que la composition d'operateurs resulte en objets
qui s'imbriquent comme sous-objets. Un operator est alors un template membre comme:

template<typename T> struct Vect {
T *m;
// ...
template<typename E>
Vect& operator=(E const &e) {
for (int i = 0; i<this->taille(); ++i) {
this->m[i] = e[i];
}
return *this;
}
// ...
}

C'est trop simplifie, mais j'espere que ca illustre l'idee generale.
Pour plus de details, voir le chapitre 18 de mon bouquin ;-)

Pour les version dynamiques (genre NewMat(, les operations resultent
d'habitudes en petits objets qui pointent vers les argument.
Donc
x+y
resulterai (par exemple) en un petit objet the type SommeDyn
qui pointe vers les objets x et y (contrairement aux expression
templates qui s'imbriquent directement comme sous-objets).

Comme l'operator[] est assez couteux, il n'est pas utilise comme
la base des operations. L'alternative pratique est que l'operator invoque un mini-interpreteur de l'arbre representant l'expression
a la droite. Par example, pour des matrices:

A = A*B + C;

l'operator= recoit un arbre comme

SommeDyn:
MultDyn:
Mat: A
Mat: B
Mat: C

L'interpreteur fait un passe pour assigner les matrices/vecteurs
temporaires et/ou la destination des resultat et ensuite appelle
des routines specialisee pour le calcul. Dans ce cas ci, la
sequence d'appel de ces routine pourrait etre:

MatMulDroite(A, B)
MatSomme(A, C)

(si la premiere passe a suffisament d'inteligence).

David

Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:

google@vandevoorde.com (Daveed Vandevoorde) writes:

| Bonjour a tous,

Salut !

| Je n'ai pas ecrit de francais depuis plus de quinze ans.
| Mes excuses les plus Belges pour les fotes. (Ah, et mon
| clavier n'a pas d'accents faciles. ;-)

Ton clavier s'est trompé et a tapé "fr." devant compl.lang.c++ et
viré ".moderated" à l'insue de ton plein gré ? ;-)

Non: Je lis fr.comp.lang.c++ de temps en temps (bien que
rarement). D'habitude j'y atteri quand je fait une recherche
Google pour mon nom.

(Lire le francais n'est pas une probleme: C'est l'ecrit que
j'ai perdu.)

David

Daveed Vandevoorde wrote in message <52f2f9cd.0407081731.7602fa7a@posting.google.com>:

darkman_spam@yahoo.fr (drkm) wrote in message news:<8b283176.0407071735.362bdd8a@posting.google.com>...

Daveed Vandevoorde wrote in message <52f2f9cd.0407070820.79ddd0d5@posting.google.com>

Bonjour a tous,

Je n'ai pas ecrit de francais depuis plus de quinze ans.
Mes excuses les plus Belges pour les fotes. (Ah, et mon
clavier n'a pas d'accents faciles. ;-)

Je schrijft als een Franstalige ;-)

Maar ik ben in feite oorspronkelijk Franstalig (dwz.,
m'n moedertaal is Frans niettegenstaande m'n
familienaam).

J'avais lu quelque part que tu avais étudié à la VUB. Ca plus ton
nom, difficile de ne pas tirer de conclusion :-)

La technique basee sur les templates s'apelle "expression
templates". La version dynamique (non-template) tombe
dans la grande categorie "lazy evaluation" (evaluation
paresseuse?).

Merci.

Si je peux entrevoir quelques détails, je n'arrive pas à imaginer
exactement l'ensemble. Quelqu'un a-t-il un exemple simple mais
complet ?

Je n'en ai pas la tout de suite. L'idee general est que
les operateur cree des objets representant l'operation
et que l'operator= accepte ces objets et les evaluent.

Pour les "expression template" chaque objet a un operator[]
en-ligne plus ou moins comme ceci:

[...]

Merci pour ces détails techniques.

C'est trop simplifie, mais j'espere que ca illustre l'idee generale.
Pour plus de details, voir le chapitre 18 de mon bouquin ;-)

C'est en projet depuis un an. En compétition avec quelques autres.
Lorsque je trouverai du temps :-(

Côté technique, je vois donc ce qui est employé. Mais j'ai du mal à
en imaginer le contexte d'utilisation exact. Je vais essayer de
trouver des exemples existants. Il me semble avoir lu un article sur
le sujet dans le CUJ d'il y a quelques mois. Et quelques
bibliothèques de chez Boost utilisent cette technique, si je ne
m'abuse. je devrais donc trouver des exemples facilement.

[...]

--drkm