julien pommier writes:
| Bonjour à tous,
|
| Je cherche une classe qui me permettrait de gèrer efficacement de pet its
| vecteurs (petits mais de taille variable, inférieure à 8, génér alement
| égale à 2 ou 3, et nombreux), principalement de "double". Pour l'in stant
| ce sont des std::vector<double>, mais le coût en terme de mémoire e st un
| peu élevé: dans le std::vector il y a 3 pointeurs, qui prennent 12
octets| sur une archi 32 bits classique, et 24 sur une machine 64 bits.
Donc sur| mon pc, un std::vector<double> v(2) consomme 28 octets.
Ces petits comptes me surprendront toujours.
Quelles sont les besoins de ton programme ? Quelles sont les
alternatives ? Quels sont les avantages et les inconvénients ?
Tant que des réponses claires et nettes ne sont pas apportées à ces
questions, je trouverai les petits comptes ci-haut sans aucun intérêt .
| J'ai jeté un oeil aux valarray<double>, qui n'ont que deux membres da ns
la
C'est une mauvaise idée de regarder derrière la scène.
Ça reste instructif, même si les double underscore partout demandent un
| structure (pointeur+taille), donc ça permet de gagner 4 ou 8 octets p ar
| rapport aux std::vector sur la taille de l'objet. Mais par contre ils
| utilisent le new[] pour faire les allocations, qui rajoute
| systématiquement 8 octets à la taille du bloc alloué (au moins ic i sur
une| debian/g++-3.3.2), du coup (sur mon pc), un std::valarray<double>
v(2)| consomme 32 octets.
Et tu crois que std::allocator<T> fait quoi ?
| Et j'en arrive donc à ma question: pour quelle raison le valarray
| n'utilise-t-il pas les allocateurs (auxquels je ne connais rien donc la
| réponse est peut-etre triviale) ? à moins que le std::allocator ait un
| surcoût mémoire à peu près équivalent à celui de new (auque l cas vous
| pouvez mettre ce message à la poubelle) ?
Je poserais plutôt la question dans l'autre sens : pourquoi
std::valarray<> utiliserait un std::allocator<> ?
Je la prends et je la retourne: pourquoi pas ? honnetement je ne connais
| Une troisième possibilité que j'envisage, c'est de refaire une clas se
| "from scratch" qui utilise le std::allocator<double>, et une feinte un
peu| dégueu sur les pointeurs: puisque les adresses retournées par
| std::allocator<double> seront alignés sur une adresse multiple de 8
| (d'ailleurs j'aimerais bien savoir dans quelle mesure cette hypothèse
est| valable),
Elle est *fortement* dépendante de ta machine, du compilateur et des
versions du compilateur. Qu'est-ce que tu gagnes ? Cela eb vaut-il la
peine ? Ne peux-tu pas envisager des alternatives élégantes ?
| ça laisse de la place pour stocker la taille du vecteur dans les
| 3 bits de poids faible du pointeur.
jusqu'au jour où tu as un allocateur traçant qui fait trucs dans ton
dos. Et là KABOUM! Quel est le gain ?
Si tu utilises des sortes de bitfields pour stocker la taille, il te
faut des séquences d'instructions pour extraire le vrai pointeur à
chaque fois que tu veux déréférencer un pointeur. Optimises-tu vrai ment ?
Il te faut aussi connaître un type intégral compatible avecton
pointeur. Bref que des problèmes.
| Du coup le coût d'un vecteur de taille
| n <= 8 est simplement sizeof(double*) + n*sizeof(double), soit 20 oct ets
| pour un vecteur de 2 double.
|
| Pour l'instant j'hésite.. j'aurais bien utilisé valarray parce qu'on
peut| compter sur ses performances pour les calculs, mais en définitive
c'est| celui qui consomme le plus de mémoire.
Tu utiliseras valarray s'il convient aux besoins de ton
programme. Pareil pour vector. Donc la question est, pourquoi
utilises-tu vector (ou valarray) ? Il te faut une réponse claire.
Sinon, ces micro optimisations (qui en fait ne sont pas des
optimisations) ne te créeront que des problèmes.
julien pommier <pommier@gmm.insa-tlse.fr> writes:
| Bonjour à tous,
|
| Je cherche une classe qui me permettrait de gèrer efficacement de pet its
| vecteurs (petits mais de taille variable, inférieure à 8, génér alement
| égale à 2 ou 3, et nombreux), principalement de "double". Pour l'in stant
| ce sont des std::vector<double>, mais le coût en terme de mémoire e st un
| peu élevé: dans le std::vector il y a 3 pointeurs, qui prennent 12
octets| sur une archi 32 bits classique, et 24 sur une machine 64 bits.
Donc sur| mon pc, un std::vector<double> v(2) consomme 28 octets.
Ces petits comptes me surprendront toujours.
Quelles sont les besoins de ton programme ? Quelles sont les
alternatives ? Quels sont les avantages et les inconvénients ?
Tant que des réponses claires et nettes ne sont pas apportées à ces
questions, je trouverai les petits comptes ci-haut sans aucun intérêt .
| J'ai jeté un oeil aux valarray<double>, qui n'ont que deux membres da ns
la
C'est une mauvaise idée de regarder derrière la scène.
Ça reste instructif, même si les double underscore partout demandent un
| structure (pointeur+taille), donc ça permet de gagner 4 ou 8 octets p ar
| rapport aux std::vector sur la taille de l'objet. Mais par contre ils
| utilisent le new[] pour faire les allocations, qui rajoute
| systématiquement 8 octets à la taille du bloc alloué (au moins ic i sur
une| debian/g++-3.3.2), du coup (sur mon pc), un std::valarray<double>
v(2)| consomme 32 octets.
Et tu crois que std::allocator<T> fait quoi ?
| Et j'en arrive donc à ma question: pour quelle raison le valarray
| n'utilise-t-il pas les allocateurs (auxquels je ne connais rien donc la
| réponse est peut-etre triviale) ? à moins que le std::allocator ait un
| surcoût mémoire à peu près équivalent à celui de new (auque l cas vous
| pouvez mettre ce message à la poubelle) ?
Je poserais plutôt la question dans l'autre sens : pourquoi
std::valarray<> utiliserait un std::allocator<> ?
Je la prends et je la retourne: pourquoi pas ? honnetement je ne connais
| Une troisième possibilité que j'envisage, c'est de refaire une clas se
| "from scratch" qui utilise le std::allocator<double>, et une feinte un
peu| dégueu sur les pointeurs: puisque les adresses retournées par
| std::allocator<double> seront alignés sur une adresse multiple de 8
| (d'ailleurs j'aimerais bien savoir dans quelle mesure cette hypothèse
est| valable),
Elle est *fortement* dépendante de ta machine, du compilateur et des
versions du compilateur. Qu'est-ce que tu gagnes ? Cela eb vaut-il la
peine ? Ne peux-tu pas envisager des alternatives élégantes ?
| ça laisse de la place pour stocker la taille du vecteur dans les
| 3 bits de poids faible du pointeur.
jusqu'au jour où tu as un allocateur traçant qui fait trucs dans ton
dos. Et là KABOUM! Quel est le gain ?
Si tu utilises des sortes de bitfields pour stocker la taille, il te
faut des séquences d'instructions pour extraire le vrai pointeur à
chaque fois que tu veux déréférencer un pointeur. Optimises-tu vrai ment ?
Il te faut aussi connaître un type intégral compatible avecton
pointeur. Bref que des problèmes.
| Du coup le coût d'un vecteur de taille
| n <= 8 est simplement sizeof(double*) + n*sizeof(double), soit 20 oct ets
| pour un vecteur de 2 double.
|
| Pour l'instant j'hésite.. j'aurais bien utilisé valarray parce qu'on
peut| compter sur ses performances pour les calculs, mais en définitive
c'est| celui qui consomme le plus de mémoire.
Tu utiliseras valarray s'il convient aux besoins de ton
programme. Pareil pour vector. Donc la question est, pourquoi
utilises-tu vector (ou valarray) ? Il te faut une réponse claire.
Sinon, ces micro optimisations (qui en fait ne sont pas des
optimisations) ne te créeront que des problèmes.
julien pommier writes:
| Bonjour à tous,
|
| Je cherche une classe qui me permettrait de gèrer efficacement de pet its
| vecteurs (petits mais de taille variable, inférieure à 8, génér alement
| égale à 2 ou 3, et nombreux), principalement de "double". Pour l'in stant
| ce sont des std::vector<double>, mais le coût en terme de mémoire e st un
| peu élevé: dans le std::vector il y a 3 pointeurs, qui prennent 12
octets| sur une archi 32 bits classique, et 24 sur une machine 64 bits.
Donc sur| mon pc, un std::vector<double> v(2) consomme 28 octets.
Ces petits comptes me surprendront toujours.
Quelles sont les besoins de ton programme ? Quelles sont les
alternatives ? Quels sont les avantages et les inconvénients ?
Tant que des réponses claires et nettes ne sont pas apportées à ces
questions, je trouverai les petits comptes ci-haut sans aucun intérêt .
| J'ai jeté un oeil aux valarray<double>, qui n'ont que deux membres da ns
la
C'est une mauvaise idée de regarder derrière la scène.
Ça reste instructif, même si les double underscore partout demandent un
| structure (pointeur+taille), donc ça permet de gagner 4 ou 8 octets p ar
| rapport aux std::vector sur la taille de l'objet. Mais par contre ils
| utilisent le new[] pour faire les allocations, qui rajoute
| systématiquement 8 octets à la taille du bloc alloué (au moins ic i sur
une| debian/g++-3.3.2), du coup (sur mon pc), un std::valarray<double>
v(2)| consomme 32 octets.
Et tu crois que std::allocator<T> fait quoi ?
| Et j'en arrive donc à ma question: pour quelle raison le valarray
| n'utilise-t-il pas les allocateurs (auxquels je ne connais rien donc la
| réponse est peut-etre triviale) ? à moins que le std::allocator ait un
| surcoût mémoire à peu près équivalent à celui de new (auque l cas vous
| pouvez mettre ce message à la poubelle) ?
Je poserais plutôt la question dans l'autre sens : pourquoi
std::valarray<> utiliserait un std::allocator<> ?
Je la prends et je la retourne: pourquoi pas ? honnetement je ne connais
| Une troisième possibilité que j'envisage, c'est de refaire une clas se
| "from scratch" qui utilise le std::allocator<double>, et une feinte un
peu| dégueu sur les pointeurs: puisque les adresses retournées par
| std::allocator<double> seront alignés sur une adresse multiple de 8
| (d'ailleurs j'aimerais bien savoir dans quelle mesure cette hypothèse
est| valable),
Elle est *fortement* dépendante de ta machine, du compilateur et des
versions du compilateur. Qu'est-ce que tu gagnes ? Cela eb vaut-il la
peine ? Ne peux-tu pas envisager des alternatives élégantes ?
| ça laisse de la place pour stocker la taille du vecteur dans les
| 3 bits de poids faible du pointeur.
jusqu'au jour où tu as un allocateur traçant qui fait trucs dans ton
dos. Et là KABOUM! Quel est le gain ?
Si tu utilises des sortes de bitfields pour stocker la taille, il te
faut des séquences d'instructions pour extraire le vrai pointeur à
chaque fois que tu veux déréférencer un pointeur. Optimises-tu vrai ment ?
Il te faut aussi connaître un type intégral compatible avecton
pointeur. Bref que des problèmes.
| Du coup le coût d'un vecteur de taille
| n <= 8 est simplement sizeof(double*) + n*sizeof(double), soit 20 oct ets
| pour un vecteur de 2 double.
|
| Pour l'instant j'hésite.. j'aurais bien utilisé valarray parce qu'on
peut| compter sur ses performances pour les calculs, mais en définitive
c'est| celui qui consomme le plus de mémoire.
Tu utiliseras valarray s'il convient aux besoins de ton
programme. Pareil pour vector. Donc la question est, pourquoi
utilises-tu vector (ou valarray) ? Il te faut une réponse claire.
Sinon, ces micro optimisations (qui en fait ne sont pas des
optimisations) ne te créeront que des problèmes.
julien pommier writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier <pommier@gmm.insa-tlse.fr> writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier <pommier@gmm.insa-tlse.fr> writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier <pommier@gmm.insa-tlse.fr> writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
julien pommier writes:
| Ce qui m'ennuie (un peu), ce n'est pas seulement les 28 octets, mais
aussi| que quand je parcoure un std::vector<point>, chaque élement du
vecteur| occupe 12 octets, et sur ces douze, il y en a toute une partie
qui ne| m'interesse pas (en gros le pointeur qui permet de redimensionner
les| vecteurs), celle là elle vient polluer le cache et tout ça.
| A vrai dire même le membre qui contient la dimension d'un point ne
| m'interesse pas puisqu'on peut supposer que tous les points de la
collection| font la même taille, mais là je n'ai pas trop d'idée po ur
gèrer| intelligement (et simplement) une collection de points, en pouva nt
| extraire/ajouter des points, sans dupliquer leur taille.
est-ce que cette taille est connue à la compilation (je présume que
non, mais je pose quand même la question). Sinon, la solution
classique, consiste à allouer un gros bout de mémoire et à voir cet te
mémoire comme une suite de petits points :
(1) pas de duplication de taille
(2) données consécutives
(3) pas d'allocation/deallocation intempestives
Tu implémentes cette vue par une classe wrapper autour du double* brute.
Hmm, valarray, c'est pour les tableaux de taille moyenne et plus.
C'est plus efficace quand on fait les operations sur place -- ou alors
il faut utiliser les expressions templates (comme tu as dû le voir
dans le code source). Les classes std::slice et std::slice_array
sont un exemple de l'implémentation de vue dont je parlais -- dans ton
cas, où on a encore plus d'information, on peut faire mieux.
[...]
| Pour l'instant c'est vector, pour des raisons historiques. Je pense que
le| passage à valarray pour tous les vecteurs "gros" se fera de toute
façon.| Mais pour les petits, au vu du bench sur la dec que je n'avais pas
encore| fait tourner, je vais peut-etre me laisser tenter par le côté
obscur
As-tu vraiment besoin de retourner par valeur, ou peux-tu calculer sur
place? Parce que si tu peux calculer sur place, en utilisant les
expressions templates, alors tu veux allouer une fois pour toute et
utiliser des classes qui ont la taille d'un pointeur.
En général, j'utilise quand même les classes imbriquées dans les
templates. J'exprime les contraintes différemment
En général, j'utilise quand même les classes imbriquées dans les
templates. J'exprime les contraintes différemment
En général, j'utilise quand même les classes imbriquées dans les
templates. J'exprime les contraintes différemment
