Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
vitesse c++ vs Java
64 views
Skip to first unread message
xfredox
Sep 1, 2012, 9:03:01 AM9/1/12
to
Bonjour,
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 ?
par avance, merci
Fred
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 ?
par avance, merci
Fred
Marc
Sep 1, 2012, 9:33:48 AM9/1/12
to
les programmes ne doivent pas �tre bien longs, �a aiderait de pouvoir y
jeter un oeil avant de r�pondre. La notion de "grand nombre" est en
particulier assez floue...
Le nom du compilateur, les options, la machine dessous, sont d'autres
infos qui pourraient servir.
xfredox
Sep 1, 2012, 2:13:51 PM9/1/12
to
Le 01/09/2012 15:33, Marc a �crit :
Bonsoir,
Ci-dessous le code en java: (9 secondes)
public class premier
{
public static void main (String[] args)
{
int i;
float b=0;
for (i=1;i<2000000000;i++)//
{b=b+(float)+1/i;}
System.out.println(b);
}
}
Maintenant le code en C++: (15 secondes)
#include <iostream>
using namespace std;
int main()
{
int i;
float b=0;
for(i=1;i<2000000000;i++)
{
b=b+(float)1/i;
}
cout << "Resultat: "<< b<< endl;
return 0;
}
Je suis sous ubuntu 12.04 64
J'utilise eclipse pour java et code:block pour c++
A noter que si je passe en ligne de commande les temps sont relativement
les m�mes (� quelques dixi�mes de secondes)
(en ligne de commande j'utilise java 6 et g++)
J'ai les m�mes r�sultats sous w7
Comment expliquer une telle diff�rence ? Comment y rem�dier ?
par avance, merci
Fred
Ci-dessous le code en java: (9 secondes)
public class premier
{
public static void main (String[] args)
{
int i;
float b=0;
for (i=1;i<2000000000;i++)//
{b=b+(float)+1/i;}
System.out.println(b);
}
}
Maintenant le code en C++: (15 secondes)
#include <iostream>
using namespace std;
int main()
{
int i;
float b=0;
for(i=1;i<2000000000;i++)
{
b=b+(float)1/i;
}
cout << "Resultat: "<< b<< endl;
return 0;
}
Je suis sous ubuntu 12.04 64
J'utilise eclipse pour java et code:block pour c++
A noter que si je passe en ligne de commande les temps sont relativement
les m�mes (� quelques dixi�mes de secondes)
(en ligne de commande j'utilise java 6 et g++)
J'ai les m�mes r�sultats sous w7
Comment expliquer une telle diff�rence ? Comment y rem�dier ?
par avance, merci
Fred
Marc Espie
Sep 1, 2012, 2:38:54 PM9/1/12
to
In article <5042505f$0$2381$426a...@news.free.fr>,
Toujours aucunes options de compile (qui sont sans doute differentes).
De facon plus interessante, ca ne sert pas a grand chose d'avoir un programme
qui affiche un resultat completement faux.
Je viens de regarder ton code C++:
Resultat: 15.4037
et avec des double:
Resultat: 21.9936
La deuxieme valeur etant relativement proche de la realite,
qui est ln 2000000000 + gamma =~ 21.9941
a 1/4000000000 pres...
De facon plus interessante, ca ne sert pas a grand chose d'avoir un programme
qui affiche un resultat completement faux.
Je viens de regarder ton code C++:
Resultat: 15.4037
et avec des double:
Resultat: 21.9936
La deuxieme valeur etant relativement proche de la realite,
qui est ln 2000000000 + gamma =~ 21.9941
a 1/4000000000 pres...
xfredox
Sep 1, 2012, 3:35:11 PM9/1/12
to
Le 01/09/2012 20:38, Marc Espie a �crit :
Je viens de faire quelques tests apr�s quelques recherches sur le web:
code:block ne met aucune option d'optimisation par d�faut (un g++ en
ligne de commande sans option �quivaut � l'IDE puisque les temps
d'ex�cution sont les m�mes)
en ligne de commande je ne mettais aucune option car je n'aurais jamais
pens� qu'il y avait une telle diff�rence (et surtout je ne les
connaissais pas)
Dans un premier temps je suis pass� au type double (en fait � partir
d'un certain moment le float ne sert plus � rien dans l'addition d'un
inverse dans ce cas l�) donc c'est comme si il ne se passait plus rien.
Le double est donc plus adapt� (merci pour la remarque, je n'y avais pas
pens�)
En ligne de commande
java: 17s
sans optimisation:
c++ 20
Java gagne encore
Eclipse java :14s
Code:block c++ 20s
Bizarre...
Avec optimisation:
g++ -O3 -s main.cpp 13s
g++ -Ofast -s main.cpp 7s
Eclipse doit faire une ou deux petite(s) optimisation(s) puisque c'est
plus rapide que la ligne de commande (et dire que je pensais qu'un IDE
c'�tait forc�ment plus long)
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'elle
augmente de fa�on tangible la vitesse (je n'ai pas vraiment trouv� de
description dessus sur le net), une id�e ?
peut-on encore faire mieux ?
bonne soir�e
code:block ne met aucune option d'optimisation par d�faut (un g++ en
ligne de commande sans option �quivaut � l'IDE puisque les temps
d'ex�cution sont les m�mes)
en ligne de commande je ne mettais aucune option car je n'aurais jamais
pens� qu'il y avait une telle diff�rence (et surtout je ne les
connaissais pas)
Dans un premier temps je suis pass� au type double (en fait � partir
d'un certain moment le float ne sert plus � rien dans l'addition d'un
inverse dans ce cas l�) donc c'est comme si il ne se passait plus rien.
Le double est donc plus adapt� (merci pour la remarque, je n'y avais pas
pens�)
En ligne de commande
java: 17s
sans optimisation:
c++ 20
Java gagne encore
Eclipse java :14s
Code:block c++ 20s
Bizarre...
Avec optimisation:
g++ -O3 -s main.cpp 13s
g++ -Ofast -s main.cpp 7s
Eclipse doit faire une ou deux petite(s) optimisation(s) puisque c'est
plus rapide que la ligne de commande (et dire que je pensais qu'un IDE
c'�tait forc�ment plus long)
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'elle
augmente de fa�on tangible la vitesse (je n'ai pas vraiment trouv� de
description dessus sur le net), une id�e ?
peut-on encore faire mieux ?
bonne soir�e
Fabien LE LEZ
Sep 1, 2012, 3:41:26 PM9/1/12
to
On Sat, 01 Sep 2012 21:35:11 +0200, xfredox <xfr...@free.fr>:
>J'ai trouv� l'option fast en cherchant dans le man de g++
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Optimize-Options.html
-Ofast
Disregard strict standards compliance. -Ofast enables all -O3
optimizations. It also enables optimizations that are not valid for
all standard compliant programs. It turns on -ffast-math.
>J'ai trouv� l'option fast en cherchant dans le man de g++
-Ofast
Disregard strict standards compliance. -Ofast enables all -O3
optimizations. It also enables optimizations that are not valid for
all standard compliant programs. It turns on -ffast-math.
xfredox
Sep 1, 2012, 3:43:34 PM9/1/12
to
Le 01/09/2012 21:41, Fabien LE LEZ a �crit :
Merci , comme �a en plus je saurais o� regarder pour toutes les autres
options (c t pas complet sur la commande man)
et en fran�ais �a donne quoi ? :D
options (c t pas complet sur la commande man)
et en fran�ais �a donne quoi ? :D
Marc Espie
Sep 1, 2012, 4:32:08 PM9/1/12
to
In article <5042636f$0$1854$426a...@news.free.fr>,
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...
En tres simplifie, pour du calcul "standard" dans des conditions
usuelles, ca va marcher. Pour des trucs un peu aux limites, -ffast-math
peut te donner un resultat (faux) la ou ca devrait foirer...
c'est tout un domaine un peu orthogonal au C++ lui-meme, les calculs
flottants etant generalement couverts par une autre norme, IEEE 754.
xfredox <xfr...@free.fr> wrote:
>g++ -O3 -s main.cpp 13s
>g++ -Ofast -s main.cpp 7s
>
>Eclipse doit faire une ou deux petite(s) optimisation(s) puisque c'est
>plus rapide que la ligne de commande (et dire que je pensais qu'un IDE
>c'�tait forc�ment plus long)
>
>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'elle
>augmente de fa�on tangible la vitesse (je n'ai pas vraiment trouv� de
>description dessus sur le net), une id�e ?
Tout processeur moderne est "pipeline" avec l'execution de plusieurs
>g++ -O3 -s main.cpp 13s
>g++ -Ofast -s main.cpp 7s
>
>Eclipse doit faire une ou deux petite(s) optimisation(s) puisque c'est
>plus rapide que la ligne de commande (et dire que je pensais qu'un IDE
>c'�tait forc�ment plus long)
>
>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'elle
>augmente de fa�on tangible la vitesse (je n'ai pas vraiment trouv� de
>description dessus sur le net), une id�e ?
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...
En tres simplifie, pour du calcul "standard" dans des conditions
usuelles, ca va marcher. Pour des trucs un peu aux limites, -ffast-math
peut te donner un resultat (faux) la ou ca devrait foirer...
c'est tout un domaine un peu orthogonal au C++ lui-meme, les calculs
flottants etant generalement couverts par une autre norme, IEEE 754.
Marc
Sep 1, 2012, 5:21:20 PM9/1/12
to
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'elle
>>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
>>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'elle
>>augmente de fa�on tangible la vitesse (je n'ai pas vraiment trouv� de
>>description dessus sur le net), une id�e ?
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...
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.
Fabien LE LEZ
Sep 1, 2012, 9:47:02 PM9/1/12
to
On Sat, 01 Sep 2012 21:43:34 +0200, xfredox <xfr...@free.fr>:
>et en fran�ais �a donne quoi
Essaie http://translate.google.com/
>et en fran�ais �a donne quoi
Jean-Marc Desperrier
Sep 3, 2012, 6:53:15 AM9/3/12
to
xfredox a �crit :
D�j� que les optimisations parfaitement autoris�es par le standard
donnent r�guli�rement des r�sultats qui semblent inattendus pour les
d�veloppeurs, mais si le programme s'autorise � ne pas les respecter ...
Je ne dirais qu'on ne peut s'autoriser l'option que pour de tout petit
morceaux de programme pour lequel on a des test de conformit� o� on
v�rifie la conformit� dans tous les cas de figure possible.
Ca me fait penser qu'un vraiment bon compilateur remplacerait tout ton
code, et en restant totalement "standard compliant", par :
printf("Resultat: 21.9936");
> et en fran�ais �a donne quoi ? :D
C'est plus rapide, mais il n'est pas sur que cela marche encore.
D�j� que les optimisations parfaitement autoris�es par le standard
donnent r�guli�rement des r�sultats qui semblent inattendus pour les
d�veloppeurs, mais si le programme s'autorise � ne pas les respecter ...
Je ne dirais qu'on ne peut s'autoriser l'option que pour de tout petit
morceaux de programme pour lequel on a des test de conformit� o� on
v�rifie la conformit� dans tous les cas de figure possible.
Ca me fait penser qu'un vraiment bon compilateur remplacerait tout ton
code, et en restant totalement "standard compliant", par :
printf("Resultat: 21.9936");
Marc Espie
Sep 3, 2012, 8:07:48 AM9/3/12
to
In article <k22244$c2m$1...@writer.imaginet.fr>,
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.
confere
http://en.wikipedia.org/wiki/Harmonic_number
On y trouve:
Hn = ln n + gamma + 1/2n - 1/12n2 + 1/120n4 - ...
ca converge TRES vite.
Jean-Marc Desperrier <jmd...@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
>Ca me fait penser qu'un vraiment bon compilateur remplacerait tout ton
>code, et en restant totalement "standard compliant", par :
> printf("Resultat: 21.9936");
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.
confere
http://en.wikipedia.org/wiki/Harmonic_number
On y trouve:
Hn = ln n + gamma + 1/2n - 1/12n2 + 1/120n4 - ...
ca converge TRES vite.
ld
Sep 3, 2012, 9:14:20 AM9/3/12
to
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
> Marc Espie wrote:
> >>Par contre effectivement dans le meilleur des cas, le C++ devient deux
> >>fois plus rapide que Java, impressionnant ! (et logique)
> >>ne sais pas exactement comment elle fonctionne en dehors du fait qu'elle
> >>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
> > 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...
>
> 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
> 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
> 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.
Marc Espie
Sep 3, 2012, 9:42:22 AM9/3/12
to
In article <f29f448a-5f3a-4e1b...@p12g2000vbm.googlegroups.com>,
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 <laurent...@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
>-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.
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
Sep 4, 2012, 2:25:53 AM9/4/12
to
On 3 sep, 15:42, es...@lain.home (Marc Espie) wrote:
> In article <f29f448a-5f3a-4e1b-b008-0c3de58ed...@p12g2000vbm.googlegroups.com>,
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.
> In article <f29f448a-5f3a-4e1b-b008-0c3de58ed...@p12g2000vbm.googlegroups.com>,
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.
0 new messages