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).
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.
C'est étonnant. En principe les méthodes et opérateurs template de valarray devraient s'instancier en donnant un code approximativement identique. Il est possible que ça vienne d'options de compilation, en particulier de la vérification des bornes des indices. Peux-tu poster le bout de code en question ? -- Philippe Guglielmetti - www.dynabits.com
delta" <singularcusp@yahoo.fr> a écrit dans le message de
news:bo5tto024ui@enews2.newsguy.com
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.
C'est étonnant. En principe les méthodes et opérateurs template de valarray
devraient s'instancier en donnant un code approximativement identique.
Il est possible que ça vienne d'options de compilation, en particulier de la
vérification des bornes des indices.
Peux-tu poster le bout de code en question ?
--
Philippe Guglielmetti - www.dynabits.com
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.
C'est étonnant. En principe les méthodes et opérateurs template de valarray devraient s'instancier en donnant un code approximativement identique. Il est possible que ça vienne d'options de compilation, en particulier de la vérification des bornes des indices. Peux-tu poster le bout de code en question ? -- Philippe Guglielmetti - www.dynabits.com
delta
"Philippe Guglielmetti" a écrit dans le message de news:3fa74dc9$0$3657$
Bonjour,
merci de ta reponse Philippe, et desole pour le format deplorable du message.
C'est étonnant. En principe les méthodes et opérateurs template de valarray devraient s'instancier en donnant un code approximativement identique. Il est possible que ça vienne d'options de compilation, en particulier de
la vérification des bornes des indices. Peux-tu poster le bout de code en question ?
Avec plaisir, car j espere vraiment user incorrectement des valarrays tant leur confort d ecriture est appreciable. Voici donc qqs extraits de code. La declaration de la classe ressemble a ceci :
L une des methodes appelee intensivement, est par exemple, la suivante ; les lignes originales qui calculent en valarray sont commentees et remplacees par leur "equivalent" a l aide d une boucle.
De plus, 2 autres methodes similaires a rkck12 (donnant cependant lieu a plus d evalutions du champ de vecteurs) sont potentiellement appelees des que l erreur de consistance est suffisament petite.
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message de
news:3fa74dc9$0$3657$5402220f@news.sunrise.ch...
Bonjour,
merci de ta reponse Philippe, et desole pour le format deplorable
du message.
C'est étonnant. En principe les méthodes et opérateurs template de
valarray devraient s'instancier en donnant un code approximativement
identique. Il est possible que ça vienne d'options de compilation, en
particulier de
la vérification des bornes des indices.
Peux-tu poster le bout de code en question ?
Avec plaisir, car j espere vraiment user incorrectement des valarrays
tant leur confort d ecriture est appreciable. Voici donc qqs extraits de
code. La declaration de la classe ressemble a ceci :
L une des methodes appelee intensivement, est par exemple, la suivante ;
les lignes originales qui calculent en valarray sont commentees et
remplacees
par leur "equivalent" a l aide d une boucle.
De plus, 2 autres methodes similaires a rkck12 (donnant cependant
lieu a plus d evalutions du champ de vecteurs) sont potentiellement
appelees des que l erreur de consistance est suffisament petite.
"Philippe Guglielmetti" a écrit dans le message de news:3fa74dc9$0$3657$
Bonjour,
merci de ta reponse Philippe, et desole pour le format deplorable du message.
C'est étonnant. En principe les méthodes et opérateurs template de valarray devraient s'instancier en donnant un code approximativement identique. Il est possible que ça vienne d'options de compilation, en particulier de
la vérification des bornes des indices. Peux-tu poster le bout de code en question ?
Avec plaisir, car j espere vraiment user incorrectement des valarrays tant leur confort d ecriture est appreciable. Voici donc qqs extraits de code. La declaration de la classe ressemble a ceci :
L une des methodes appelee intensivement, est par exemple, la suivante ; les lignes originales qui calculent en valarray sont commentees et remplacees par leur "equivalent" a l aide d une boucle.
De plus, 2 autres methodes similaires a rkck12 (donnant cependant lieu a plus d evalutions du champ de vecteurs) sont potentiellement appelees des que l erreur de consistance est suffisament petite.
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça (je ne les ai personnellement jamais utilisés) ?
Chris
Laurent Deniau
Christophe Lephay wrote:
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça (je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
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 -- ]
Christophe Lephay wrote:
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1;
for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h *
m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris :
y1 = m_k1;
y1 *= h;
y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça
(je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
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 -- ]
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça (je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
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 -- ]
"A program compiled with /Op may be slower and larger than one compiled without /Op. Note The /Op option disables inline generation of floating-point functions. The standard run-time library routines are used instead. For more information, see the /Oi option."
et comme la STL est faite de plein de petites fonctions que le compilateur a tendance à mettre inline... 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... -- Philippe Guglielmetti - www.dynabits.com
"delta" <singularcusp@yahoo.fr> a écrit dans le message de
news:bo87na02905@enews4.newsguy.com...
"A program compiled with /Op may be slower and larger than one compiled
without /Op. Note The /Op option disables inline generation of
floating-point functions. The standard run-time library routines are used
instead. For more information, see the /Oi option."
et comme la STL est faite de plein de petites fonctions que le compilateur a
tendance à mettre inline...
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...
--
Philippe Guglielmetti - www.dynabits.com
"A program compiled with /Op may be slower and larger than one compiled without /Op. Note The /Op option disables inline generation of floating-point functions. The standard run-time library routines are used instead. For more information, see the /Oi option."
et comme la STL est faite de plein de petites fonctions que le compilateur a tendance à mettre inline... 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... -- Philippe Guglielmetti - www.dynabits.com
delta
"Christophe Lephay" a écrit dans le message de news:bo8d9l$mln$
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça
(je ne les ai personnellement jamais utilisés) ?
Si c est le cas, je prefere encore une boucle. Honnetement je n ai pas teste cette ecriture. Imaginons que j ai 3 vecteurs qui s expriment comme combinaison lineaire de 7 autres, et ceci dans 3 methodes distinctes ; je fais comment ?
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:bo8d9l$mln$1@news-reader4.wanadoo.fr...
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1;
for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h *
m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris :
y1 = m_k1;
y1 *= h;
y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire
ça
(je ne les ai personnellement jamais utilisés) ?
Si c est le cas, je prefere encore une boucle. Honnetement je n ai pas teste
cette ecriture. Imaginons que j ai 3 vecteurs qui s expriment comme
combinaison
lineaire de 7 autres, et ceci dans 3 methodes distinctes ; je fais comment ?
"Christophe Lephay" a écrit dans le message de news:bo8d9l$mln$
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça
(je ne les ai personnellement jamais utilisés) ?
Si c est le cas, je prefere encore une boucle. Honnetement je n ai pas teste cette ecriture. Imaginons que j ai 3 vecteurs qui s expriment comme combinaison lineaire de 7 autres, et ceci dans 3 methodes distinctes ; je fais comment ?
delta
"Laurent Deniau" a écrit dans le message de news:
Christophe Lephay wrote:
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire ça
(je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
Euh oui, c est bien ce que j en attends :-) D ailleurs, aussi rapide ou plus rapide ?
"Laurent Deniau" <Laurent.Deniau@cern.ch> a écrit dans le message de
news:3FA7B9E3.80304@cern.ch...
Christophe Lephay wrote:
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1;
for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h *
m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris :
y1 = m_k1;
y1 *= h;
y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire
ça
(je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
Euh oui, c est bien ce que j en attends :-) D ailleurs, aussi rapide ou
plus rapide ?
"A program compiled with /Op may be slower and larger than one compiled without /Op. Note The /Op option disables inline generation of floating-point functions. The standard run-time library routines are used instead. For more information, see the /Oi option."
et comme la STL est faite de plein de petites fonctions que le compilateur a
tendance à mettre inline...
Ok, j ai apercu une lueur d espoir mais ca ne suffit pas. Le gain n est pas significatif (incomparable en regard du gain obtenu en remplacant par une boucle ; je ne comprends pas d ailleurs, comment c est possible). Commencons par le commencement peut-etre. Le code que j ai poste (la version valarray donc, qui est commentee ds le message precedent) montre t il des lacunes evidentes en terme de rapidite ? Un piege classique du c++ a l affut du programmeur debutant que je suis ? Qqchose ayant trait a la construction des objets ?
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 ... :-)
"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message de
news:3fa7ca02$0$3654$5402220f@news.sunrise.ch...
"delta" <singularcusp@yahoo.fr> a écrit dans le message de
news:bo87na02905@enews4.newsguy.com...
"A program compiled with /Op may be slower and larger than one compiled
without /Op. Note The /Op option disables inline generation of
floating-point functions. The standard run-time library routines are used
instead. For more information, see the /Oi option."
et comme la STL est faite de plein de petites fonctions que le compilateur
a
tendance à mettre inline...
Ok, j ai apercu une lueur d espoir mais ca ne suffit pas. Le gain n est pas
significatif (incomparable en regard du gain obtenu en remplacant par une
boucle ;
je ne comprends pas d ailleurs, comment c est possible).
Commencons par le commencement peut-etre.
Le code que j ai poste (la version valarray donc, qui est commentee ds
le message precedent) montre t il des lacunes evidentes en terme de rapidite
?
Un piege classique du c++ a l affut du programmeur debutant que je suis ?
Qqchose ayant trait a la construction des objets ?
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 ... :-)
"A program compiled with /Op may be slower and larger than one compiled without /Op. Note The /Op option disables inline generation of floating-point functions. The standard run-time library routines are used instead. For more information, see the /Oi option."
et comme la STL est faite de plein de petites fonctions que le compilateur a
tendance à mettre inline...
Ok, j ai apercu une lueur d espoir mais ca ne suffit pas. Le gain n est pas significatif (incomparable en regard du gain obtenu en remplacant par une boucle ; je ne comprends pas d ailleurs, comment c est possible). Commencons par le commencement peut-etre. Le code que j ai poste (la version valarray donc, qui est commentee ds le message precedent) montre t il des lacunes evidentes en terme de rapidite ? Un piege classique du c++ a l affut du programmeur debutant que je suis ? Qqchose ayant trait a la construction des objets ?
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 ... :-)
Laurent Deniau
delta wrote:
"Laurent Deniau" a écrit dans le message de news:
Christophe Lephay wrote:
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire
ça
(je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
Euh oui, c est bien ce que j en attends :-) D ailleurs, aussi rapide ou plus rapide ?
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 :-)
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 wrote:
"Laurent Deniau" <Laurent.Deniau@cern.ch> a écrit dans le message de
news:3FA7B9E3.80304@cern.ch...
Christophe Lephay wrote:
Christophe de VIENNE wrote:
delta wrote:
//y1 = ystart + h * m_k1;
for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h *
m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris :
y1 = m_k1;
y1 *= h;
y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire
ça
(je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
Euh oui, c est bien ce que j en attends :-) D ailleurs, aussi rapide ou
plus rapide ?
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 :-)
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 -- ]
//y1 = ystart + h * m_k1; for (size_t i = 0 ; i< m_Dimension; ++i) y1[i] = ystart[i] + h * m_k1[i];
Au risque de dire une bêtise, qu'est-ce que ça donne si tu écris : y1 = m_k1; y1 *= h; y1 += ystart;
N'est-ce pas, du reste, l'intérêt des valarray que de permettre de faire
ça
(je ne les ai personnellement jamais utilisés) ?
L'interet des valarray est justement d'ecrire
y1 = ystart + h*m_k1;
directement et que ce soit aussi rapide que la boucle proposee...
Euh oui, c est bien ce que j en attends :-) D ailleurs, aussi rapide ou plus rapide ?
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 :-)
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 -- ]
