Le conteneur valarray a recemment ete aborde relativement a une classe
Vecteur.
J avais l intention d ecrire un petit algorithme de resolution d edo a 1 pas
(neanmoins, a pas et ordre variables), c est pourquoi l arithmetique du
valarray
m a seduit ...
Cependant, les resultats, en terme de performance, sont catastrophiques : le
temps
de calcul est environ 10 fois plus important lorsque j utilise les
operateurs du
valarray que lorsque j ai recours a une boucle for. J avoue que Stroustrup m
avait
pourtant suffisament alleche, de sorte que je reste sur ma faim (c est le
moins que
je puisse dire).
Par ailleurs, il evoque un principe de "lazy evaluation" mais je n arrive
pas a
combler le code entre les lignes. Ainsi, peut-etre que son sentiment s
appuie sur
une optimisation qui atomise tout ...
En vous remerciant.
PS : au risque que l on m envoie voir ailleurs, j ajoute que je programme a
l aide
de vs .net 7.1 (qui possede une stl raisonnable, d apres la rumeur).
"Philippe Guglielmetti" a écrit dans le message de
Si j'ai bien compris cette option, elle n'est utile que si tu compares (intensivement) des nombres, ce qui ne semble pas être ton cas. Et de toute manière fabs(a-b)<epsilon est toujours préférable à a==b...
J evite de tester l egalite de 2 reels, effectivement ... :-)
En parlant de réels, est ce que f/2.0 est aussi efficace que f*0.5 ? Ou vaut t il mieux utiliser la multiplication ?
-------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
delta wrote:
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message de
Si j'ai bien compris cette option, elle n'est utile que si tu compares
(intensivement) des nombres, ce qui ne semble pas être ton cas.
Et de toute manière fabs(a-b)<epsilon est toujours préférable à a==b...
J evite de tester l egalite de 2 reels, effectivement ... :-)
En parlant de réels, est ce que f/2.0 est aussi efficace que f*0.5 ?
Ou vaut t il mieux utiliser la multiplication ?
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/
"Philippe Guglielmetti" a écrit dans le message de
Si j'ai bien compris cette option, elle n'est utile que si tu compares (intensivement) des nombres, ce qui ne semble pas être ton cas. Et de toute manière fabs(a-b)<epsilon est toujours préférable à a==b...
J evite de tester l egalite de 2 reels, effectivement ... :-)
En parlant de réels, est ce que f/2.0 est aussi efficace que f*0.5 ? Ou vaut t il mieux utiliser la multiplication ?
-------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Luc Hermitte
Laurent Deniau wrote in news::
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je considere comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui qui les a ecrit et si je me souviens bien il s'est bien casse la tete sur les benchs pour que soit au moins aussi rapide :-)
J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz ++ ne concerne pas les derniers valarray...
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in
news:3FA7E41B.5000804@cern.ch:
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je
considere comme negligeable. Ca peut aussi etre plus lent du meme
ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera
surement plus d'info, c'est lui qui les a ecrit et si je me souviens
bien il s'est bien casse la tete sur les benchs pour que soit au moins
aussi rapide :-)
J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz
++ ne concerne pas les derniers valarray...
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je considere comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui qui les a ecrit et si je me souviens bien il s'est bien casse la tete sur les benchs pour que soit au moins aussi rapide :-)
J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz ++ ne concerne pas les derniers valarray...
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
delta
"Laurent Deniau" a écrit dans le message de news:
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je considere
comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur. Pour
les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui qui
les a ecrit et si je me souviens bien il s'est bien casse la tete sur les benchs
pour que soit au moins aussi rapide :-)
Oui j aimerais bien que Gaby nous donne son point de vue :-) Par ailleurs, si l un d entre vous possede VS2003 et qu il utilise les valarrays, je serais interesse par son impression sur l efficacite du conteneur, sur cette plateforme. Parce que la, je desespere ...
PS : quitte a utiliser des indices, autant changer les valarrays en vector. Et la je tombe sur un article recommandant d utiliser des iterateurs en lieu et place des indices "entiers" ... pour raisons d efficacite (je pense a une bete boucle). Info ou intox ?
Merci.
"Laurent Deniau" <Laurent.Deniau@cern.ch> a écrit dans le message de
news:3FA7E41B.5000804@cern.ch...
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je
considere
comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur.
Pour
les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui
qui
les a ecrit et si je me souviens bien il s'est bien casse la tete sur les
benchs
pour que soit au moins aussi rapide :-)
Oui j aimerais bien que Gaby nous donne son point de vue :-) Par ailleurs,
si
l un d entre vous possede VS2003 et qu il utilise les valarrays, je serais
interesse par son impression sur l efficacite du conteneur, sur cette
plateforme.
Parce que la, je desespere ...
PS : quitte a utiliser des indices, autant changer les valarrays en vector.
Et la
je tombe sur un article recommandant d utiliser des iterateurs en lieu et
place
des indices "entiers" ... pour raisons d efficacite (je pense a une bete
boucle).
Info ou intox ?
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je considere
comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur. Pour
les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui qui
les a ecrit et si je me souviens bien il s'est bien casse la tete sur les benchs
pour que soit au moins aussi rapide :-)
Oui j aimerais bien que Gaby nous donne son point de vue :-) Par ailleurs, si l un d entre vous possede VS2003 et qu il utilise les valarrays, je serais interesse par son impression sur l efficacite du conteneur, sur cette plateforme. Parce que la, je desespere ...
PS : quitte a utiliser des indices, autant changer les valarrays en vector. Et la je tombe sur un article recommandant d utiliser des iterateurs en lieu et place des indices "entiers" ... pour raisons d efficacite (je pense a une bete boucle). Info ou intox ?
Merci.
Philippe Guglielmetti
"delta" a écrit dans le message de news:
PS : quitte a utiliser des indices, autant changer les valarrays en vector.
les valarrays sont implémentés de façon très similaire aux vector. La doc dit: The sequence is stored as an array of T.
Et la je tombe sur un article recommandant d utiliser des iterateurs en lieu et
place des indices "entiers" ... pour raisons d efficacite (je pense a une bete
boucle). Info ou intox ?
l'indiçage avec des entiers requiert une multiplication par la taille d'un élément (comme pour un bête tableau C) alors que les itérateurs (implémentés comme des pointeurs) peuvent être incrémentés/décrémentés par addition/soustraction. Ca devrait permettre de grapiller des microsecondes, et c'est en principe ce que devraient faire les fameux opérateurs inclus dans valarray... A mon avis ton problème est ailleurs. J'utilise les valarray en VC6, mais pas trop intensivement donc je n'ai pas vraiment fait attention à la performance.
En cherchant, j'ai trouvé un (vieil) article un peu inquiétant : http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html et des avis intéressants sur http://www.experts-exchange.com/Programming/Programming_Languages/Cplusplus/Q_20703035.html Apparemment http://www.oonumerics.org/blitz/ offre de meilleures performances que valarray. -- Philippe Guglielmetti - www.dynabits.com
"delta" <singularcusp@yahoo.fr> a écrit dans le message de
news:boaarn023so@enews3.newsguy.com...
PS : quitte a utiliser des indices, autant changer les valarrays en
vector.
les valarrays sont implémentés de façon très similaire aux vector. La doc
dit:
The sequence is stored as an array of T.
Et la je tombe sur un article recommandant d utiliser des iterateurs en
lieu et
place des indices "entiers" ... pour raisons d efficacite (je pense a une
bete
boucle).
Info ou intox ?
l'indiçage avec des entiers requiert une multiplication par la taille d'un
élément (comme pour un bête tableau C) alors que les itérateurs (implémentés
comme des pointeurs) peuvent être incrémentés/décrémentés par
addition/soustraction. Ca devrait permettre de grapiller des microsecondes,
et c'est en principe ce que devraient faire les fameux opérateurs inclus
dans valarray...
A mon avis ton problème est ailleurs. J'utilise les valarray en VC6, mais
pas trop intensivement donc je n'ai pas vraiment fait attention à la
performance.
En cherchant, j'ai trouvé un (vieil) article un peu inquiétant :
http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html
et des avis intéressants sur
http://www.experts-exchange.com/Programming/Programming_Languages/Cplusplus/Q_20703035.html
Apparemment http://www.oonumerics.org/blitz/ offre de meilleures
performances que valarray.
--
Philippe Guglielmetti - www.dynabits.com
PS : quitte a utiliser des indices, autant changer les valarrays en vector.
les valarrays sont implémentés de façon très similaire aux vector. La doc dit: The sequence is stored as an array of T.
Et la je tombe sur un article recommandant d utiliser des iterateurs en lieu et
place des indices "entiers" ... pour raisons d efficacite (je pense a une bete
boucle). Info ou intox ?
l'indiçage avec des entiers requiert une multiplication par la taille d'un élément (comme pour un bête tableau C) alors que les itérateurs (implémentés comme des pointeurs) peuvent être incrémentés/décrémentés par addition/soustraction. Ca devrait permettre de grapiller des microsecondes, et c'est en principe ce que devraient faire les fameux opérateurs inclus dans valarray... A mon avis ton problème est ailleurs. J'utilise les valarray en VC6, mais pas trop intensivement donc je n'ai pas vraiment fait attention à la performance.
En cherchant, j'ai trouvé un (vieil) article un peu inquiétant : http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html et des avis intéressants sur http://www.experts-exchange.com/Programming/Programming_Languages/Cplusplus/Q_20703035.html Apparemment http://www.oonumerics.org/blitz/ offre de meilleures performances que valarray. -- Philippe Guglielmetti - www.dynabits.com
Laurent Deniau
Luc Hermitte wrote:
Laurent Deniau wrote in news::
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je considere comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui qui les a ecrit et si je me souviens bien il s'est bien casse la tete sur les benchs pour que soit au moins aussi rapide :-)
J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz ++ ne concerne pas les derniers valarray...
Je pense. Car il n'y a aucune raison pour que les valarray soient plus lent que Blitz++. Le papier cite date de 1997 alors que les techniques utilisees par Blitz++ se sont repandues la meme annee (96-97). Il y a de forte chance que les valarray utilises dans le bench aient ete implementes de facon naive.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Luc Hermitte wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in
news:3FA7E41B.5000804@cern.ch:
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je
considere comme negligeable. Ca peut aussi etre plus lent du meme
ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera
surement plus d'info, c'est lui qui les a ecrit et si je me souviens
bien il s'est bien casse la tete sur les benchs pour que soit au moins
aussi rapide :-)
J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz
++ ne concerne pas les derniers valarray...
Je pense. Car il n'y a aucune raison pour que les valarray soient plus lent que
Blitz++. Le papier cite date de 1997 alors que les techniques utilisees par
Blitz++ se sont repandues la meme annee (96-97). Il y a de forte chance que les
valarray utilises dans le bench aient ete implementes de facon naive.
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je considere comme negligeable. Ca peut aussi etre plus lent du meme ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera surement plus d'info, c'est lui qui les a ecrit et si je me souviens bien il s'est bien casse la tete sur les benchs pour que soit au moins aussi rapide :-)
J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz ++ ne concerne pas les derniers valarray...
Je pense. Car il n'y a aucune raison pour que les valarray soient plus lent que Blitz++. Le papier cite date de 1997 alors que les techniques utilisees par Blitz++ se sont repandues la meme annee (96-97). Il y a de forte chance que les valarray utilises dans le bench aient ete implementes de facon naive.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
delta
"Philippe Guglielmetti" a écrit dans le message de news:3fa8c134$0$3675$
les valarrays sont implémentés de façon très similaire aux vector. La doc dit: The sequence is stored as an array of T.
Bien, je vais peut-etre m en tenir aux vectors en definitive.
l'indiçage avec des entiers requiert une multiplication par la taille d'un élément (comme pour un bête tableau C) alors que les itérateurs (implémentés
comme des pointeurs) peuvent être incrémentés/décrémentés par addition/soustraction. Ca devrait permettre de grapiller des microsecondes,
et c'est en principe ce que devraient faire les fameux opérateurs inclus dans valarray...
ok, merci :)
A mon avis ton problème est ailleurs.
Oui mais ou ? je confirme que lorsque je remplace par une boucle ... je gagne un facteur 10 :-(
J'utilise les valarray en VC6, mais pas trop intensivement donc je n'ai pas vraiment fait attention à la performance.
A vrai dire, je ne l aurais peut-etre pas remarque non plus, de suite au moins. Mais, j ai voulu comparer avec une ancienne methode un peu moins robuste et donc potentiellement plus rapide, implementee a l aide de vectors (j ai mm imagine que les valrrays pourraient compenser le cout d une robustesse accrue ; sur le long terme, en presque raide, ca pouvait etre tres interessant). Des lors, le test ne fait que ca, calculer une solution d edo, et je n ai vraiment pas presume que le type de base en etait l origine. Une fois que j avais epuise le cout (du nombre d appels) des evaluations du champ, cout de l integration et cout du controle ... il ne restait plus que la structure de donnees, elle mm. Bref :-(
En cherchant, j'ai trouvé un (vieil) article un peu inquiétant : http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html et des avis intéressants sur
Apparemment http://www.oonumerics.org/blitz/ offre de meilleures performances que valarray.
Merci, merci et merci :-)
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message de
news:3fa8c134$0$3675$5402220f@news.sunrise.ch...
les valarrays sont implémentés de façon très similaire aux vector. La doc
dit:
The sequence is stored as an array of T.
Bien, je vais peut-etre m en tenir aux vectors en definitive.
l'indiçage avec des entiers requiert une multiplication par la taille d'un
élément (comme pour un bête tableau C) alors que les itérateurs
(implémentés
comme des pointeurs) peuvent être incrémentés/décrémentés par
addition/soustraction. Ca devrait permettre de grapiller des
microsecondes,
et c'est en principe ce que devraient faire les fameux opérateurs inclus
dans valarray...
ok, merci :)
A mon avis ton problème est ailleurs.
Oui mais ou ? je confirme que lorsque je remplace par une boucle
... je gagne un facteur 10 :-(
J'utilise les valarray en VC6, mais
pas trop intensivement donc je n'ai pas vraiment fait attention à la
performance.
A vrai dire, je ne l aurais peut-etre pas remarque non plus,
de suite au moins. Mais, j ai voulu comparer avec une ancienne
methode un peu moins robuste et donc potentiellement plus
rapide, implementee a l aide de vectors (j ai mm imagine que
les valrrays pourraient compenser le cout d une robustesse
accrue ; sur le long terme, en presque raide, ca pouvait etre
tres interessant). Des lors, le test ne fait que ca, calculer une
solution d edo, et je n ai vraiment pas presume que le type
de base en etait l origine. Une fois que j avais epuise le cout
(du nombre d appels) des evaluations du champ, cout de
l integration et cout du controle ... il ne restait plus que la
structure de donnees, elle mm. Bref :-(
En cherchant, j'ai trouvé un (vieil) article un peu inquiétant :
http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html
et des avis intéressants sur
"Philippe Guglielmetti" a écrit dans le message de news:3fa8c134$0$3675$
les valarrays sont implémentés de façon très similaire aux vector. La doc dit: The sequence is stored as an array of T.
Bien, je vais peut-etre m en tenir aux vectors en definitive.
l'indiçage avec des entiers requiert une multiplication par la taille d'un élément (comme pour un bête tableau C) alors que les itérateurs (implémentés
comme des pointeurs) peuvent être incrémentés/décrémentés par addition/soustraction. Ca devrait permettre de grapiller des microsecondes,
et c'est en principe ce que devraient faire les fameux opérateurs inclus dans valarray...
ok, merci :)
A mon avis ton problème est ailleurs.
Oui mais ou ? je confirme que lorsque je remplace par une boucle ... je gagne un facteur 10 :-(
J'utilise les valarray en VC6, mais pas trop intensivement donc je n'ai pas vraiment fait attention à la performance.
A vrai dire, je ne l aurais peut-etre pas remarque non plus, de suite au moins. Mais, j ai voulu comparer avec une ancienne methode un peu moins robuste et donc potentiellement plus rapide, implementee a l aide de vectors (j ai mm imagine que les valrrays pourraient compenser le cout d une robustesse accrue ; sur le long terme, en presque raide, ca pouvait etre tres interessant). Des lors, le test ne fait que ca, calculer une solution d edo, et je n ai vraiment pas presume que le type de base en etait l origine. Une fois que j avais epuise le cout (du nombre d appels) des evaluations du champ, cout de l integration et cout du controle ... il ne restait plus que la structure de donnees, elle mm. Bref :-(
En cherchant, j'ai trouvé un (vieil) article un peu inquiétant : http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html et des avis intéressants sur
| Oui j aimerais bien que Gaby nous donne son point de vue :-) Par ailleurs,
il le fera bientôt.
[c'est fou ce que ce groupe peut produire en moins de deux semaines :-)]
-- Gaby
Gabriel Dos Reis
Luc Hermitte writes:
| Laurent Deniau wrote in | news:: | | > Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je | > considere comme negligeable. Ca peut aussi etre plus lent du meme | > ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera | > surement plus d'info, c'est lui qui les a ecrit et si je me souviens | > bien il s'est bien casse la tete sur les benchs pour que soit au moins | > aussi rapide :-) | | J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz | ++ ne concerne pas les derniers valarray...
Ces benchs sont d'un temps très ancien et ne concernent pas forcément les produits appropriés. Par exemple, je crois que la bibliothèque de VC n'utilisent pas les expressions templates ; certaines implémentations se contentent juste d'implémenter valarray comme un autre moyen d'écrire vector. Ces implémentations sont conformes mais peu utiles.
-- Gaby
Luc Hermitte <hermitte@free.fr.invalid> writes:
| Laurent Deniau <Laurent.Deniau@cern.ch> wrote in
| news:3FA7E41B.5000804@cern.ch:
|
| > Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je
| > considere comme negligeable. Ca peut aussi etre plus lent du meme
| > ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera
| > surement plus d'info, c'est lui qui les a ecrit et si je me souviens
| > bien il s'est bien casse la tete sur les benchs pour que soit au moins
| > aussi rapide :-)
|
| J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz
| ++ ne concerne pas les derniers valarray...
Ces benchs sont d'un temps très ancien et ne concernent pas
forcément les produits appropriés.
Par exemple, je crois que la bibliothèque de VC n'utilisent pas les
expressions templates ; certaines implémentations se contentent juste
d'implémenter valarray comme un autre moyen d'écrire vector.
Ces implémentations sont conformes mais peu utiles.
| Laurent Deniau wrote in | news:: | | > Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je | > considere comme negligeable. Ca peut aussi etre plus lent du meme | > ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera | > surement plus d'info, c'est lui qui les a ecrit et si je me souviens | > bien il s'est bien casse la tete sur les benchs pour que soit au moins | > aussi rapide :-) | | J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz | ++ ne concerne pas les derniers valarray...
Ces benchs sont d'un temps très ancien et ne concernent pas forcément les produits appropriés. Par exemple, je crois que la bibliothèque de VC n'utilisent pas les expressions templates ; certaines implémentations se contentent juste d'implémenter valarray comme un autre moyen d'écrire vector. Ces implémentations sont conformes mais peu utiles.
-- Gaby
Gabriel Dos Reis
Laurent Deniau writes:
| Luc Hermitte wrote: | > Laurent Deniau wrote in | > news:: | > | > | >>Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je | >>considere comme negligeable. Ca peut aussi etre plus lent du meme | >>ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera | >>surement plus d'info, c'est lui qui les a ecrit et si je me souviens | >>bien il s'est bien casse la tete sur les benchs pour que soit au moins | >>aussi rapide :-) | > | > | > J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz | > ++ ne concerne pas les derniers valarray... | | Je pense. Car il n'y a aucune raison pour que les valarray soient plus lent que | Blitz++. Le papier cite date de 1997 alors que les techniques utilisees par | Blitz++ se sont repandues la meme annee (96-97). Il y a de forte chance que les | valarray utilises dans le bench aient ete implementes de facon naive.
en réalité, GCC par exemple ne contenait pas de valarray quand ce papier a été écrit. J'ai écrit valarray trois fois. La première mouture était finie en Sept 1997 et n'a été officiellement dans EGCS que vers fin Dec 1997. La seconde fois, c'était vers la fin 1998. La troisième fois deviat être vers fin 1999 (je n'ai plus la date exacte en tête).
Les implémentations de 1997 étaient « naives » et n'utilisaient pas la technique décrite dans le papier de Todd -- même si David Vandevoorde s'était battu pour que cette technique soit autorisée. Alors la comparaison est facile :-)
-- Gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| Luc Hermitte wrote:
| > Laurent Deniau <Laurent.Deniau@cern.ch> wrote in
| > news:3FA7E41B.5000804@cern.ch:
| >
| >
| >>Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je
| >>considere comme negligeable. Ca peut aussi etre plus lent du meme
| >>ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera
| >>surement plus d'info, c'est lui qui les a ecrit et si je me souviens
| >>bien il s'est bien casse la tete sur les benchs pour que soit au moins
| >>aussi rapide :-)
| >
| >
| > J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz
| > ++ ne concerne pas les derniers valarray...
|
| Je pense. Car il n'y a aucune raison pour que les valarray soient plus lent que
| Blitz++. Le papier cite date de 1997 alors que les techniques utilisees par
| Blitz++ se sont repandues la meme annee (96-97). Il y a de forte chance que les
| valarray utilises dans le bench aient ete implementes de facon naive.
en réalité, GCC par exemple ne contenait pas de valarray quand ce
papier a été écrit. J'ai écrit valarray trois fois. La première
mouture était finie en Sept 1997 et n'a été officiellement dans EGCS
que vers fin Dec 1997. La seconde fois, c'était vers la fin 1998. La
troisième fois deviat être vers fin 1999 (je n'ai plus la date exacte
en tête).
Les implémentations de 1997 étaient « naives » et n'utilisaient pas la
technique décrite dans le papier de Todd -- même si David Vandevoorde
s'était battu pour que cette technique soit autorisée. Alors la
comparaison est facile :-)
| Luc Hermitte wrote: | > Laurent Deniau wrote in | > news:: | > | > | >>Ca peut etre plus rapide mais pas de beaucoup (max 5-10%) ce que je | >>considere comme negligeable. Ca peut aussi etre plus lent du meme | >>ordre de grandeur. Pour les valarray de GCC 3.0+, Gaby te donnera | >>surement plus d'info, c'est lui qui les a ecrit et si je me souviens | >>bien il s'est bien casse la tete sur les benchs pour que soit au moins | >>aussi rapide :-) | > | > | > J'en déduis que les benchs des valarrays que l'on voit sur le site de Blitz | > ++ ne concerne pas les derniers valarray... | | Je pense. Car il n'y a aucune raison pour que les valarray soient plus lent que | Blitz++. Le papier cite date de 1997 alors que les techniques utilisees par | Blitz++ se sont repandues la meme annee (96-97). Il y a de forte chance que les | valarray utilises dans le bench aient ete implementes de facon naive.
en réalité, GCC par exemple ne contenait pas de valarray quand ce papier a été écrit. J'ai écrit valarray trois fois. La première mouture était finie en Sept 1997 et n'a été officiellement dans EGCS que vers fin Dec 1997. La seconde fois, c'était vers la fin 1998. La troisième fois deviat être vers fin 1999 (je n'ai plus la date exacte en tête).
Les implémentations de 1997 étaient « naives » et n'utilisaient pas la technique décrite dans le papier de Todd -- même si David Vandevoorde s'était battu pour que cette technique soit autorisée. Alors la comparaison est facile :-)
-- Gaby
delta
"Benoit Rousseau" a écrit dans le message de news:3fa7f0bb$0$29045$
En parlant de réels, est ce que f/2.0 est aussi efficace que f*0.5 ? Ou vaut t il mieux utiliser la multiplication ?
J ai ca si ca t interesse, mm si cette page date un peu :
