De la vitesse des langages...

De la vitesse des langages... - Divers - Programmation

Marsh Posté le 09-01-2004 à 18:19:15    

C est rapide comme l'éclair, java est lent. On entend souvent parler de vitesse d'éxécution de programme suivant leur langage. OsNews vient de publier un super benchmark entre plusieurs langages : Java 1.3.1, Java 1.4.2, C compilé avec gcc 3.3.1, Python 2.3.2, Python compilé avec Psyco 1.1.1, et les quatres langages de Visual Studio .NET 2003 : Visual Basic, Visual C#, Visual C++, et Visual J#.
 
En conclusion, quoi en retenir :
 
http://img.osnews.com/img/5602/results.jpg
 
- Les différents langages de microsofts sont très rapides, et occupent 4 des 5 premières places.
- gcc est plus lent que visual C++, confirmant ainsi ses rumeurs de charettes
- java 1.4 est plus lent que le 1.3, contrairement à ce que raconte sun.
- Python n'apparait pas dans le tableau tellement il est lent (même en compilé), puisque 40 fois plus lent que le visual C++.
- si on exclue le calcul trigonométrique, java est du même niveau que les autres langages de microsoft.
 
 
La news : http://osnews.com/story.php?news_id=5602


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 09-01-2004 à 18:19:15   

Reply

Marsh Posté le 09-01-2004 à 18:35:43    

Bon, je réouvre, mais faut que ce soit pour discuter sérieusement.
Ne pas oublier que si jamais vous voulez troller, y a ce topic-là :
 
http://forum.hardware.fr/forum2.ph [...] post=31321


Message édité par antp le 09-01-2004 à 19:02:59

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
Reply

Marsh Posté le 09-01-2004 à 19:03:21    

bon ben si qqun sait pkoi java se vautre comme ca en trig....

Reply

Marsh Posté le 09-01-2004 à 19:17:56    

chrisbk a écrit :

bon ben si qqun sait pkoi java se vautre comme ca en trig....


 
code source :  
http://www.ocf.berkeley.edu/~cowel [...] hmark.java
 
Pour infos, Math.sin délègue à StrictMath.sin  qui est une méthode native.


Message édité par kadreg le 09-01-2004 à 19:22:18

---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 09-01-2004 à 19:25:16    

En même temps qui c'est qui l'a codé le bench ? P'tet que le mec est juste meilleur en C++ qu'en java....
Sinon ca comprend quoi au juste le calcul trigonométrique ?
 
EDIT : ouais j'ai rien dis, je viens de lire le code et y'a pas à être bon ou pas..
 
EDIT2 : en fait ce qui me surprend le plus c'est les bonnes perfs de java en I/O, j'ai toujours pensé que c'était son point faible.


Message édité par R3g le 09-01-2004 à 19:28:40
Reply

Marsh Posté le 09-01-2004 à 19:45:36    

kadreg a écrit :


 
code source :  
http://www.ocf.berkeley.edu/~cowel [...] hmark.java
 
Pour infos, Math.sin délègue à StrictMath.sin  qui est une méthode native.


 
et donc ?

Reply

Marsh Posté le 09-01-2004 à 20:12:12    

kadreg a écrit :


- java 1.4 est plus lent que le 1.3, contrairement à ce que raconte sun.

juste pour la trig. je trouve ça bcp trop louche pour être honnete.

Reply

Marsh Posté le 09-01-2004 à 20:24:42    

c est quoi le sens de ce graphe??? sachant que derriere il y a un scheduleur qui gere le temps alloue aux taches par le proc ?????

Reply

Marsh Posté le 09-01-2004 à 21:02:42    

si t'enlèves la trigo, Java 1.4.2 est pas mal


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 09-01-2004 à 21:10:20    

avec la version du benchmark en java j'arrive vraiment très très près de ses valeurs mis à part pour la trigo où c'est environ 4 secondes plus rapide...
 
en espèrant que sun corrige la trigo dans java 1.5...


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 09-01-2004 à 21:10:20   

Reply

Marsh Posté le 09-01-2004 à 21:18:49    

chrisbk a écrit :


et donc ?


 
C'est plus un problème d'implémentation dans la bibliothèque standard (écrite en C) qu'un problème de langage.


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 09-01-2004 à 21:21:17    

kadreg a écrit :


 
C'est plus un problème d'implémentation dans la bibliothèque standard (écrite en C) qu'un problème de langage.


 
eurf, je vois pas comment on peut se planter dans ce genre de fonctions

Reply

Marsh Posté le 09-01-2004 à 21:29:15    

je me méfie toujours de ce genre de bench, est ce vraiment représentatif de ce qui est utilisé en réalité ?

Reply

Marsh Posté le 09-01-2004 à 21:30:41    

noldor a écrit :

je me méfie toujours de ce genre de bench, est ce vraiment représentatif de ce qui est utilisé en réalité ?


 
Vieux proverbe : le meilleur benchmark est l'application que l'on compte utiliser.


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 09-01-2004 à 21:36:56    

trollesque

Reply

Marsh Posté le 09-01-2004 à 21:39:12    

1) le gcc est sous cygwin
2) le traitement int64 bits n'a aucun sens en Python
3) tiens les produits MS en premier
4) le code est loin d'être propre, c'est du travail de chaffouin
5) moi je prends le code C sur mon XP200+, je compile en -O0, je lance (seti@bg) et pan, je fais direct 49s ... super...

Reply

Marsh Posté le 09-01-2004 à 21:42:02    

taz a écrit :

1) le gcc est sous cygwin
2) le traitement int64 bits n'a aucun sens en Python
3) tiens les produits MS en premier
4) le code est loin d'être propre, c'est du travail de chaffouin
5) moi je prends le code C sur mon XP200+, je compile en -O0, je lance (seti@bg) et pan, je fais direct 49s ... super...


 
ca chiffone hein ? [:icon7]

Reply

Marsh Posté le 09-01-2004 à 21:45:44    

chrisbk a écrit :


 
ca chiffone hein ? [:icon7]

ben c'est pas très fin comme troll enfin bon chez osnews d'un autre côté, faut pas trop attendre ... leur news sur linux/le_libre sont pathétiques (pas autant que clubic qui annonce mandrake quand même)

Reply

Marsh Posté le 09-01-2004 à 21:47:12    

taz a écrit :

ben c'est pas très fin comme troll enfin bon chez osnews d'un autre côté, faut pas trop attendre ... leur news sur linux/le_libre sont pathétiques (pas autant que clubic qui annonce mandrake quand même)


 
ah, donc si un bench place les produits MS en tete c'est un troll ?
Par contre le meme bench qui aurait mis du libre en tete, ca n'aurait pas été un troll ?
 
 
Ca ma l'air compliqué tout ca [:humanrage]
 
enfin entre deux "trolls", on se bornera de signaler que VC++ est  tres utilisé dans l'industrie du JV, sont pas mauvais en optimisation chez M$ (<< cado [:icon7])
 


Message édité par chrisbk le 09-01-2004 à 21:48:28
Reply

Marsh Posté le 09-01-2004 à 21:48:58    

j'ai pas dit ça. je dis : tiens les produits MS sont en premier, la version de gcc_cywin est loin d'être la plus rapide, et bien qu'ayant une configuration plus modeste, et sans optimisation, j'obtiens avec gcc un meilleur score que VC++
 
bon t'es pas marrant ce soir

Reply

Marsh Posté le 09-01-2004 à 21:50:30    

taz a écrit :


bon t'es pas marrant ce soir


pourtant je donne tout ce que j'ai
 
au fait si j'ai bien compris c pas du C++ compilé natif (ou je me plante ?)
 
ah si je me plante


Message édité par chrisbk le 09-01-2004 à 21:51:05
Reply

Marsh Posté le 09-01-2004 à 21:52:13    

pas mauvais en optimisation, mon oeil. un rapide tour en C++ montre clairement que le compilateur ignore certaines optimisations triviales. gcc_cygwin n'est pas aussi performant qu'un vrai gcc (comme sous linux par exemple)

Reply

Marsh Posté le 09-01-2004 à 21:52:47    

taz a écrit :

pas mauvais en optimisation, mon oeil. un rapide tour en C++ montre clairement que le compilateur ignore certaines optimisations triviales. gcc_cygwin n'est pas aussi performant qu'un vrai gcc (comme sous linux par exemple)


 
fo compiler en release [:icon12]
 
c koi les optims trivials qu'il rate ? source ? preuve ? et pas du VC4 hein ? [:icon11]


Message édité par chrisbk le 09-01-2004 à 21:53:15
Reply

Marsh Posté le 09-01-2004 à 21:54:25    

bah je pense. n'ayant jamais utilisé VC, je suis mal placé, mais à chaque fois que je parle avec des gens, ils me montrent que certaines optimisations sont absentes
 
 
quand à python, quand tu vois la tronche du code, c'est tout sauf du python, faut pas s'étonner

Reply

Marsh Posté le 09-01-2004 à 21:59:08    

c'est leger comme argumentation, jeune homme, tres leger, limite trollationique [:shakalagoons]

Reply

Marsh Posté le 09-01-2004 à 22:00:34    

parce que ces benchmarks ne le sont pas ?

Reply

Marsh Posté le 09-01-2004 à 22:01:56    

ce sont des fait, froids et reproductibles, pas des on-dit, des "j'ai un pote qui dit que", ou autre truc du genre :o
 
Maintenant si le type a pris un gcc d'avant-guerre, c'est sur que cette comparaison est a oublier.  
 

Reply

Marsh Posté le 09-01-2004 à 22:05:49    

à oublier. et puis tout le monde sait que gcc est natif des *n*x sur lesquels ils règne. moi je te fais le meme truc avec wine et vc, on verra. bref gcc est pas la dans son environnement idéal.
 
et puis on teste sur une plateforme MS, les produits MS sont favoriés. je suis sur que la JVM sous solaris est bien plus rapide que ça par exemple
 
 
bon je vais au bar

Reply

Marsh Posté le 09-01-2004 à 22:10:33    

taz a écrit :

à oublier. et puis tout le monde sait que gcc est natif des *n*x sur lesquels ils règne. moi je te fais le meme truc avec wine et vc, on verra. bref gcc est pas la dans son environnement idéal.
 
et puis on teste sur une plateforme MS, les produits MS sont favoriés. je suis sur que la JVM sous solaris est bien plus rapide que ça par exemple
 
 
bon je vais au bar


une certaine lassitude m'envahi a la lecture de tout ceci. je crios meme que je vais pousser un leger baillement et voir si je peux trainer mon colloc au bar. vider des bieres, au moins, ca se passe d'os

Reply

Marsh Posté le 09-01-2004 à 22:21:32    

Les conclusions sont foireuses en effet. Java 1.4.2 est bien plus rapide que Java 1.3 sauf sur 1 seul test. Faire la somme des temps de calcul est vraiment une très très mauvaise idée.
 
Les seules conclusions que je tire de tout ça sont :
- Vous voyez bien que Java ce n'est pas si lent que ça
- Du C++ bien optimisé reste plus rapide que du C# sous .Net Pas ettonant quand même.
 
Au fait, vous savez que GCC sait faire du "profiled based optimisation" lui aussi ? -fbranch-probabilities

Reply

Marsh Posté le 09-01-2004 à 22:37:00    

Kristoph a écrit :


- Vous voyez bien que Java ce n'est pas si lent que ça


 
Selon moi (qui ne programme pas en Java) une des principales raison de cette "croyance" de lenteur de Java c'est surtout que les interfaces graphiques sont souvent pas très réactives. Un peu comme le XUL de Mozilla :/


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
Reply

Marsh Posté le 09-01-2004 à 23:00:17    

une version du bench vite fait en delphi

Code :
  1. program Benchmark;
  3. {$APPTYPE CONSOLE}
  5. uses
  6.   SysUtils,
  7.   MMSystem,
  8.   Math;
  10. var
  11.   startTime :Longint;
  12.   stopTime :Longint;
  13.   elapsedTime :Longint;
  15.   intMax :integer;
  16.   doubleMin :double;
  17.   doubleMax :double;
  18.   longMin :Int64;
  19.   longMax :Int64;
  20.   trigMax :double;
  21.   ioMax :integer;
  23.   intArithmeticTime: double;
  24.   doubleArithmeticTime :double;
  25.   longCountTime :double;
  26.   trigTime :double;
  27.   ioTime :double;
  28.   totalTime :double;
  31.   function intArithmetic(intMax:integer):Longint;
  32.   var
  33.     intResult :integer;
  34.     i :integer;
  35.   begin
  37.     startTime := timeGetTime;
  38.  intResult := 1;
  39.  i := 1;
  40.    
  41.  while (i < intMax) do
  42.  begin
  43.   intResult := intResult - i;
  44.       inc(i);
  45.       intResult := intResult + i;
  46.       inc(i);
  47.       intResult := intResult * i;
  48.       inc(i);
  49.       intResult := intResult div i;
  50.       inc(i);
  51.  end;
  53.  stopTime := timeGetTime;
  54.  elapsedTime := stopTime - startTime;
  56.  WriteLn('Int arithmetic elapsed time: ' + inttostr(elapsedTime) + 'ms with max of ' + inttostr(intMax));
  57.  WriteLn(' i: ' + inttostr(i) + ' intResult: ' + inttostr(intResult));
  58.  result := elapsedTime;
  60.   end;
  62.   function doubleArithmetic(doubleMin, doubleMax:double):Longint;
  63.   var
  64.     doubleResult :double;
  65.     i :double;
  66.   begin
  68.     startTime := timeGetTime;
  70.  doubleResult := doubleMin;
  71.  i := doubleMin;
  73.  while (i < doubleMax) do
  74.  begin
  75.   doubleResult := doubleResult - i;
  76.       i:=i+1;
  77.       doubleResult := doubleResult + i;
  78.       i:=i+1;
  79.       doubleResult := doubleResult * i;
  80.       i:=i+1;
  81.       doubleResult := doubleResult / i;
  82.       i:=i+1;
  83.  end;
  85.  stopTime := timeGetTime;
  86.  elapsedTime := stopTime - startTime;
  88.  WriteLn('Double arithmetic elapsed time: ' + inttostr(elapsedTime) + ' ms with min of ' + floattostr(doubleMin) + ', max of ' + floattostr(doubleMax));
  89.  WriteLn(' i: ' + floattostr(i) + ' doubleResult: ' + floattostr(doubleResult));
  90.  result := elapsedTime;
  93.   end;
  95.   function longArithmetic(longMin, longMax:Int64):Longint;
  96.   var
  97.     longResult :Int64;
  98.     i :Int64;
  99.   begin
  101.     startTime := timeGetTime;
  103.   longResult := longMin;
  104.   i := longMin;
  106.  while (i < longMax) do
  107.  begin
  108.       longResult := longResult - i;
  109.       inc(i);
  110.       longResult := longResult + i;
  111.       inc(i);
  112.       longResult := longResult * i;
  113.       inc(i);
  114.       longResult := longResult div i;
  115.       inc(i);
  116.  end;
  118.     stopTime := timeGetTime;
  119.  elapsedTime := stopTime - startTime;
  121.  WriteLn('Long arithmetic elapsed time: ' + inttostr(elapsedTime) + ' ms with min of ' + inttostr(longMin) + ', max of ' + inttostr(longMax));
  122.  WriteLn(' i: ' + inttostr(i));
  123.  WriteLn(' longResult: ' + inttostr(longResult));
  124.  result := elapsedTime;
  127.   end;
  129.   function trig(trigMax:double):Longint;
  130.   var
  131.     sine :double;
  132.     cosine :double;
  133.     tangent :double;
  134.     logarithm :double;
  135.     squareRoot :double;
  136.     i :double;
  137.   begin
  140.     startTime := timeGetTime;
  142.     sine := 0.0;
  143.  cosine := 0.0;
  144.  tangent := 0.0;
  145.  logarithm := 0.0;
  146.  squareRoot := 0.0;
  147.  i := 0.1;
  148.  while (i < trigMax) do
  149.     begin
  150.    sine := Sin(i);
  151.    cosine := Cos(i);
  152.    tangent := Tan(i);
  153.    logarithm := Log10(i);
  154.    squareRoot := sqrt(i);
  155.   i := i+1;
  156.  end;
  158.  stopTime := timeGetTime;
  159.  elapsedTime := stopTime - startTime;
  161.  WriteLn('Trig elapsed time: ' + inttostr(elapsedTime) + ' ms with max of ' + floattostr(trigMax));
  162.  WriteLn(' i: ' + floattostr(i));
  163.  WriteLn(' sine: ' + floattostr(sine));
  164.  WriteLn(' cosine: ' + floattostr(cosine));
  165.  WriteLn(' tangent: ' + floattostr(tangent));
  166.  WriteLn(' logarithm: ' + floattostr(logarithm));
  167.  WriteLn(' squareRoot: ' + floattostr(squareRoot));
  168.  result := elapsedTime;
  171.   end;
  173.   function io(ioMax:integer):Longint;
  174.   var
  175.     textLine :string;
  176.     i:integer;
  177.     myLine:string;
  178.     F:TextFile;
  179.   begin
  181.     startTime := timeGetTime;;
  183.     textLine := 'abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh';
  184.     i := 0;
  185.   myLine := '';
  187.     assignfile(F,'TestDelphi.txt');
  188.     rewrite(F);
  189.     while (i < ioMax) do
  190.  begin
  191.       Writeln(F,textLine);
  192.       inc(i);
  193.  end;
  195.     CloseFile(F);
  197.  stopTime := timeGetTime;
  198.  elapsedTime := stopTime - startTime;
  200.  WriteLn('IO elapsed time: ' + inttostr(elapsedTime) + ' ms with max of ' + inttostr(ioMax));
  201.  WriteLn(' i: ' + inttostr(i));
  202.  WriteLn(' myLine: ' + myLine);
  203.  result := elapsedTime;
  204.   end;
  206. begin
  207.   intMax := 1000000000;
  208.   doubleMin := 10000000000;
  209.   doubleMax := 11000000000;
  210.   longMin := 10000000000;
  211.   longMax := 11000000000;
  212.   trigMax := 10000000;
  213.   ioMax := 1000000;
  216.   WriteLn('Start Delphi benchmark');
  218.   intArithmeticTime := intArithmetic(intMax);
  219.   doubleArithmeticTime := doubleArithmetic(doubleMin, doubleMax);
  220. longCountTime := longArithmetic(longMin, longMax);
  221.  trigTime := trig(trigMax);
  222. ioTime := io(ioMax);
  223. totalTime := intArithmeticTime + doubleArithmeticTime + longCountTime + trigTime + ioTime;
  225.   WriteLn('Total Delphi benchmark time: ' + floattostr(totalTime) + ' ms');
  226.   WriteLn('End Delphi benchmark');
  228.   Readln;
  230. end.


 
dans la fonction trig j'ai fait  
 

Code :
  1. i := 0.1;


au lieu de

Code :
  1. i := 0.0;


car sinon la fonction Log10 plante
 
de plus puisque la fonction longArithmetic au lieu d'utiliser
des LongInt j'ai utiliser des Int64 car le LongInt de delphi permet pas d'aller aussi loin que les long en c....


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 09-01-2004 à 23:03:03    

Les long en C c'est 32 bits signés comme les int en C et les Integer en Delphi, non ?


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
Reply

Marsh Posté le 09-01-2004 à 23:14:11    

Il aurait été bien plus pertinent de faire les tests gcc et python sur hardware egal sous linux [:autobot]


Message édité par schnapsmann le 09-01-2004 à 23:15:27

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"
Reply

Marsh Posté le 09-01-2004 à 23:59:09    

antp a écrit :

Les long en C c'est 32 bits signés comme les int en C et les Integer en Delphi, non ?


 
dans les test  
en c il utilise le long long int (64 bit il me semble)
en java le long (64 bit)
 
sur un amd 1800+, 512 mb  
a peut prêt son p4 car j'obtient des résultat quasi identique au sien
 
moyenne 50 test:
 
int aritmetic: 8121ms
double aritmetic: 11627ms
long aritmetic: 112101ms
trigo: 3896ms
io: 3835ms
total: 139580ms
 
meilleur score en int
4ième pour les doubles
derniers pour les long
deuxième pour la trio
premier pour le io (trop bas il me semble le score...)
 


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 10-01-2004 à 00:00:37    

J'aimerais quand même voir des resultats à machine égale plustot qu'un "A vue de nez ça se vaut"

Reply

Marsh Posté le 10-01-2004 à 00:08:21    

os2 a écrit :


en c il utilise le long long int (64 bit il me semble)
 


 
avec quel compilo ? j'ai tj connu les long en 32 bits moi sur PC :??:


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
Reply

Marsh Posté le 10-01-2004 à 00:17:28    

antp a écrit :


 
avec quel compilo ? j'ai tj connu les long en 32 bits moi sur PC :??:


 
long long int et long c'est pas pareil
c'est toute spécifier au début du bench les types de donnée qu'il utilise (avec le nombre de byte)


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 10-01-2004 à 00:19:18    

pourquoi vb.net c#.net et vc++.net n'obtiennet pas les même résultats?
 
au final ils ont tous le même "bytecode"


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 10-01-2004 à 00:41:52    

Code :
  1. [kristoph@vvardenfell c++]$ ./bench
  2. Start C benchmark
  3. Int arithmetic elapsed time: 8160 ms
  4. Double arithmetic elapsed time: 6010 ms
  5. arithmetic elapsed time: 20770 ms
  6. Trig elapsed time: 3650 ms
  7. I/O elapsed time: 1090 ms
  8. Total elapsed time: 39680 ms


 
gcc 3.3.1 sur Athlon XP 1800+ avec 256Mo de ram
 

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed