j'ai essayé de faire un programme qui me calcule la somme de la série
harmonique sur des grands nombres. Quelle n'a pas été ma surprise de
constater que le programme en C++ était environ deux fois plus long que
le même programme qu'en java
Je suis à peu près certain que cela ne vient pas du programme (j'en ai
fait un de mon crû et plusieurs récupérés sur internet)
pourriez-vous m'expliquer cela ? il est vrai que je ne maîtrise pas les
subtilités du compilateur étant novice en la matière, cela pourrait-il
venir de cela ?
In article <k22244$c2m$, Jean-Marc Desperrier wrote:
Ca me fait penser qu'un vraiment bon compilateur remplacerait tout ton code, et en restant totalement "standard compliant", par : printf("Resultat: 21.9936");
Apres, comme deja mentionne, un vraiment bon programmeur(*) essaiera le code, comparera au resultat attendu (ln(n) + gamma, a 1/2n pres), et remplacera sa boucle par le resultat en question, ou plus precis si necessaire.
*: par vraiment bon programmeur, j'entend quelqu'un qui, soit a un niveau raisonnable en maths, soit applique sa paresse correctement. Cinq minutes sur wikipedia pour retrouver la somme de la serie harmonique et la valeur de gamma, puis pour constater que meme en double, les erreurs d'arrondi sont vraiment trop importantes.
On y trouve: Hn = ln n + gamma + 1/2n - 1/12n2 + 1/120n4 - ...
ca converge TRES vite.
In article <k22244$c2m$1@writer.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@gmail.com> wrote:
Ca me fait penser qu'un vraiment bon compilateur remplacerait tout ton
code, et en restant totalement "standard compliant", par :
printf("Resultat: 21.9936");
Apres, comme deja mentionne, un vraiment bon programmeur(*) essaiera le
code, comparera au resultat attendu (ln(n) + gamma, a 1/2n pres), et
remplacera sa boucle par le resultat en question, ou plus precis si
necessaire.
*: par vraiment bon programmeur, j'entend quelqu'un qui, soit a un niveau
raisonnable en maths, soit applique sa paresse correctement. Cinq minutes
sur wikipedia pour retrouver la somme de la serie harmonique et la
valeur de gamma, puis pour constater que meme en double, les erreurs
d'arrondi sont vraiment trop importantes.
In article <k22244$c2m$, Jean-Marc Desperrier wrote:
Ca me fait penser qu'un vraiment bon compilateur remplacerait tout ton code, et en restant totalement "standard compliant", par : printf("Resultat: 21.9936");
Apres, comme deja mentionne, un vraiment bon programmeur(*) essaiera le code, comparera au resultat attendu (ln(n) + gamma, a 1/2n pres), et remplacera sa boucle par le resultat en question, ou plus precis si necessaire.
*: par vraiment bon programmeur, j'entend quelqu'un qui, soit a un niveau raisonnable en maths, soit applique sa paresse correctement. Cinq minutes sur wikipedia pour retrouver la somme de la serie harmonique et la valeur de gamma, puis pour constater que meme en double, les erreurs d'arrondi sont vraiment trop importantes.
On y trouve: Hn = ln n + gamma + 1/2n - 1/12n2 + 1/120n4 - ...
ca converge TRES vite.
ld
On 1 sep, 23:27, Marc wrote:
Marc Espie wrote: >>Par contre effectivement dans le meilleur des cas, le C++ devient deux >>fois plus rapide que Java, impressionnant ! (et logique) >>J'ai trouvé l'option fast en cherchant dans le man de g++, par contre je >>ne sais pas exactement comment elle fonctionne en dehors du fait qu'ell e >>augmente de façon tangible la vitesse (je n'ai pas vraiment trouvé de >>description dessus sur le net), une idée ?
Le "fast" signifie que les opérations sur les float et les double peuvent faire n'importe quoi, tant que ça va vite. Avec de la chance, ça reste assez proche d'un résultat sensé. Parfois non.
> Tout processeur moderne est "pipeline" avec l'execution de plusieurs > instructions qui se chevauchent.
> Dans un code comme 1/i, tu peux avoir des divisions par zero, donc > stricto-sensu, tu peux etre amene a mettre un "stop" pour dire au > processeur de finir l'instruction et s'assurer qu'il n'y a pas de > division par zero avant de continuer.
> C'est globalement surtout ce genre de choses que va faire -ffast-math.. .
Bof. Là c'est surtout l'associativité de l'addition qui joue. Avec fast-math, le compilateur suppose que (a+b)+c == a+(b+c) == b+(a+ c). Cela lui permet de vectoriser le code en travaillant sur des quadruplets (i,i+1,i+2,i+3). Il utilise aussi une instruction qui donne une approximation de 1/x (plus une itération pour raffiner) au lieu de la vraie valeur.
-ffast-math correspond aux hypotheses/raccourcis par defaut de Fortran, ce qui rend les deux (trois) langages aussi rapidement "faux". C'est ce qui a longtemps fait que Fortran etait considere comme plus rapide.
a+, ld.
On 1 sep, 23:27, Marc <marc.gli...@gmail.com> wrote:
Marc Espie wrote:
>>Par contre effectivement dans le meilleur des cas, le C++ devient deux
>>fois plus rapide que Java, impressionnant ! (et logique)
>>J'ai trouvé l'option fast en cherchant dans le man de g++, par contre je
>>ne sais pas exactement comment elle fonctionne en dehors du fait qu'ell e
>>augmente de façon tangible la vitesse (je n'ai pas vraiment trouvé de
>>description dessus sur le net), une idée ?
Le "fast" signifie que les opérations sur les float et les double
peuvent faire n'importe quoi, tant que ça va vite. Avec de la chance, ça
reste assez proche d'un résultat sensé. Parfois non.
> Tout processeur moderne est "pipeline" avec l'execution de plusieurs
> instructions qui se chevauchent.
> Dans un code comme 1/i, tu peux avoir des divisions par zero, donc
> stricto-sensu, tu peux etre amene a mettre un "stop" pour dire au
> processeur de finir l'instruction et s'assurer qu'il n'y a pas de
> division par zero avant de continuer.
> C'est globalement surtout ce genre de choses que va faire -ffast-math.. .
Bof. Là c'est surtout l'associativité de l'addition qui joue. Avec
fast-math, le compilateur suppose que (a+b)+c == a+(b+c) == b+(a+ c).
Cela lui permet de vectoriser le code en travaillant sur des quadruplets
(i,i+1,i+2,i+3). Il utilise aussi une instruction qui donne une
approximation de 1/x (plus une itération pour raffiner) au lieu de la
vraie valeur.
-ffast-math correspond aux hypotheses/raccourcis par defaut de
Fortran, ce qui rend les deux (trois) langages aussi rapidement
"faux". C'est ce qui a longtemps fait que Fortran etait considere
comme plus rapide.
Marc Espie wrote: >>Par contre effectivement dans le meilleur des cas, le C++ devient deux >>fois plus rapide que Java, impressionnant ! (et logique) >>J'ai trouvé l'option fast en cherchant dans le man de g++, par contre je >>ne sais pas exactement comment elle fonctionne en dehors du fait qu'ell e >>augmente de façon tangible la vitesse (je n'ai pas vraiment trouvé de >>description dessus sur le net), une idée ?
Le "fast" signifie que les opérations sur les float et les double peuvent faire n'importe quoi, tant que ça va vite. Avec de la chance, ça reste assez proche d'un résultat sensé. Parfois non.
> Tout processeur moderne est "pipeline" avec l'execution de plusieurs > instructions qui se chevauchent.
> Dans un code comme 1/i, tu peux avoir des divisions par zero, donc > stricto-sensu, tu peux etre amene a mettre un "stop" pour dire au > processeur de finir l'instruction et s'assurer qu'il n'y a pas de > division par zero avant de continuer.
> C'est globalement surtout ce genre de choses que va faire -ffast-math.. .
Bof. Là c'est surtout l'associativité de l'addition qui joue. Avec fast-math, le compilateur suppose que (a+b)+c == a+(b+c) == b+(a+ c). Cela lui permet de vectoriser le code en travaillant sur des quadruplets (i,i+1,i+2,i+3). Il utilise aussi une instruction qui donne une approximation de 1/x (plus une itération pour raffiner) au lieu de la vraie valeur.
-ffast-math correspond aux hypotheses/raccourcis par defaut de Fortran, ce qui rend les deux (trois) langages aussi rapidement "faux". C'est ce qui a longtemps fait que Fortran etait considere comme plus rapide.
a+, ld.
espie
In article , ld wrote:
-ffast-math correspond aux hypotheses/raccourcis par defaut de Fortran, ce qui rend les deux (trois) langages aussi rapidement "faux". C'est ce qui a longtemps fait que Fortran etait considere comme plus rapide.
a+, ld.
Mouais bof. Tres loin d'etre la totalite de l'histoire. Voire meme negligeable pour l'enorme majorite des applis ou fortran torschait C/C++.
Le truc qui fait que fortran etait plus rapide, c'est l'existence de vrais tableaux, et donc de possibilite de demeler les alias et d'optimiser les boucles d'une facon impossible si tu consideres que tout est pointeur.
Plus ou moins corrige a coups de restrict (aha) puis de valarray et d'expression templates apres les travaux de Veldhuizen.
Dommage que Gaby ne traine plus trop par ici, il aurait certainement plus a dire sur le sujet...
In article <f29f448a-5f3a-4e1b-b008-0c3de58edd70@p12g2000vbm.googlegroups.com>,
ld <laurent.deniau@gmail.com> wrote:
-ffast-math correspond aux hypotheses/raccourcis par defaut de
Fortran, ce qui rend les deux (trois) langages aussi rapidement
"faux". C'est ce qui a longtemps fait que Fortran etait considere
comme plus rapide.
a+, ld.
Mouais bof. Tres loin d'etre la totalite de l'histoire. Voire meme
negligeable pour l'enorme majorite des applis ou fortran torschait
C/C++.
Le truc qui fait que fortran etait plus rapide, c'est l'existence
de vrais tableaux, et donc de possibilite de demeler les alias et d'optimiser
les boucles d'une facon impossible si tu consideres que tout est pointeur.
Plus ou moins corrige a coups de restrict (aha) puis de valarray et
d'expression templates apres les travaux de Veldhuizen.
Dommage que Gaby ne traine plus trop par ici, il aurait certainement
plus a dire sur le sujet...
-ffast-math correspond aux hypotheses/raccourcis par defaut de Fortran, ce qui rend les deux (trois) langages aussi rapidement "faux". C'est ce qui a longtemps fait que Fortran etait considere comme plus rapide.
a+, ld.
Mouais bof. Tres loin d'etre la totalite de l'histoire. Voire meme negligeable pour l'enorme majorite des applis ou fortran torschait C/C++.
Le truc qui fait que fortran etait plus rapide, c'est l'existence de vrais tableaux, et donc de possibilite de demeler les alias et d'optimiser les boucles d'une facon impossible si tu consideres que tout est pointeur.
Plus ou moins corrige a coups de restrict (aha) puis de valarray et d'expression templates apres les travaux de Veldhuizen.
Dommage que Gaby ne traine plus trop par ici, il aurait certainement plus a dire sur le sujet...
ld
On 3 sep, 15:42, (Marc Espie) wrote:
In article .com>,
ld wrote: >-ffast-math correspond aux hypotheses/raccourcis par defaut de >Fortran, ce qui rend les deux (trois) langages aussi rapidement >"faux". C'est ce qui a longtemps fait que Fortran etait considere >comme plus rapide.
>a+, ld.
Mouais bof. Tres loin d'etre la totalite de l'histoire. Voire meme negligeable pour l'enorme majorite des applis ou fortran torschait C/C++.
Le truc qui fait que fortran etait plus rapide, c'est l'existence de vrais tableaux, et donc de possibilite de demeler les alias et d'optim iser les boucles d'une facon impossible si tu consideres que tout est pointeur .
Plus ou moins corrige a coups de restrict (aha) puis de valarray et d'expression templates apres les travaux de Veldhuizen.
Dommage que Gaby ne traine plus trop par ici, il aurait certainement plus a dire sur le sujet...
Je parlais pour les calculs (i.e. associativite des operateurs, etc). L'autre aspect est biensur les hypotheses respectives sur l'aliasing. Mais la aussi les deux se valent.
Fortran avec son no-aliasing par defaut provoque chez les programmeurs le reflexe de tout copier en local pour eviter qu'un appel ulterieur ne casse tout (recursif non declare et non anticipe sur des arguments passes toujours par adresse). C par contre permet apres profiling de soit utiliser restrict, soit faire des copies locales pour mieux optimiser le code.
Perso je prefere l'approche du C, plus simple. Dans un code comme celui dont je m'occupe, (C, C++, Fortran 90, Fortran 77) ou les deux mondes s'appellent mutuellement, il est quasiment impossible de savoir ou des bugs arrivent a cause du defaut de Fortran (no-aliasing, no- recurence) et des appels recursifs indirects passant par le C...
a+, laurent.
On 3 sep, 15:42, es...@lain.home (Marc Espie) wrote:
In article <f29f448a-5f3a-4e1b-b008-0c3de58ed...@p12g2000vbm.googlegroups .com>,
ld <laurent.den...@gmail.com> wrote:
>-ffast-math correspond aux hypotheses/raccourcis par defaut de
>Fortran, ce qui rend les deux (trois) langages aussi rapidement
>"faux". C'est ce qui a longtemps fait que Fortran etait considere
>comme plus rapide.
>a+, ld.
Mouais bof. Tres loin d'etre la totalite de l'histoire. Voire meme
negligeable pour l'enorme majorite des applis ou fortran torschait
C/C++.
Le truc qui fait que fortran etait plus rapide, c'est l'existence
de vrais tableaux, et donc de possibilite de demeler les alias et d'optim iser
les boucles d'une facon impossible si tu consideres que tout est pointeur .
Plus ou moins corrige a coups de restrict (aha) puis de valarray et
d'expression templates apres les travaux de Veldhuizen.
Dommage que Gaby ne traine plus trop par ici, il aurait certainement
plus a dire sur le sujet...
Je parlais pour les calculs (i.e. associativite des operateurs, etc).
L'autre aspect est biensur les hypotheses respectives sur l'aliasing.
Mais la aussi les deux se valent.
Fortran avec son no-aliasing par defaut provoque chez les programmeurs
le reflexe de tout copier en local pour eviter qu'un appel ulterieur
ne casse tout (recursif non declare et non anticipe sur des arguments
passes toujours par adresse). C par contre permet apres profiling de
soit utiliser restrict, soit faire des copies locales pour mieux
optimiser le code.
Perso je prefere l'approche du C, plus simple. Dans un code comme
celui dont je m'occupe, (C, C++, Fortran 90, Fortran 77) ou les deux
mondes s'appellent mutuellement, il est quasiment impossible de savoir
ou des bugs arrivent a cause du defaut de Fortran (no-aliasing, no-
recurence) et des appels recursifs indirects passant par le C...
ld wrote: >-ffast-math correspond aux hypotheses/raccourcis par defaut de >Fortran, ce qui rend les deux (trois) langages aussi rapidement >"faux". C'est ce qui a longtemps fait que Fortran etait considere >comme plus rapide.
>a+, ld.
Mouais bof. Tres loin d'etre la totalite de l'histoire. Voire meme negligeable pour l'enorme majorite des applis ou fortran torschait C/C++.
Le truc qui fait que fortran etait plus rapide, c'est l'existence de vrais tableaux, et donc de possibilite de demeler les alias et d'optim iser les boucles d'une facon impossible si tu consideres que tout est pointeur .
Plus ou moins corrige a coups de restrict (aha) puis de valarray et d'expression templates apres les travaux de Veldhuizen.
Dommage que Gaby ne traine plus trop par ici, il aurait certainement plus a dire sur le sujet...
Je parlais pour les calculs (i.e. associativite des operateurs, etc). L'autre aspect est biensur les hypotheses respectives sur l'aliasing. Mais la aussi les deux se valent.
Fortran avec son no-aliasing par defaut provoque chez les programmeurs le reflexe de tout copier en local pour eviter qu'un appel ulterieur ne casse tout (recursif non declare et non anticipe sur des arguments passes toujours par adresse). C par contre permet apres profiling de soit utiliser restrict, soit faire des copies locales pour mieux optimiser le code.
Perso je prefere l'approche du C, plus simple. Dans un code comme celui dont je m'occupe, (C, C++, Fortran 90, Fortran 77) ou les deux mondes s'appellent mutuellement, il est quasiment impossible de savoir ou des bugs arrivent a cause du defaut de Fortran (no-aliasing, no- recurence) et des appels recursifs indirects passant par le C...
