Reprise du message précédent :

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

Dans le cas du c++, il ne doit pas produire du bytecode j'imagine. Il y a qu'à voir les optimisations qu'il active:

Ce sont des optimisations de compilation native, pas en bytecode.

pour le code delphi  
 
dans le test des long en faisant
 
longResult := Trunc(longResult/i);
 
au lieu de  
 
longResult := longResult div i;  
 
on obtient: 19 958 ms au lieu de 112 101ms
 
très net différence

 
Ouais mais la tu triches car tu ne fais plus la même operation. Tu ne fais plus une division sur des entiers 64bits mais sur des flottants et donc tu utilises la fpu est bien plus rapide que le cpu pour les divisions.

En fin de compte, en C++ ce sont des long 32 ou 64 bits ? parce que si on compare avec les Int64 de Delphi...

 
Si c'était du 32 bit, on obtiendrais les mêmes resultats qu'au premier test. Je ne sais pas si le type (long long) est standard mais à chaque fois que je l'ai utilisé c'était du 64 bit

long long est C99, pas C++

 
ha ouais après avoir relu les différents posts je me rends compte que j'avais lu "long" au lieu de "long long"

Merci de ce post, c'est tout à fait ce que je pense
Effectivement, faire la somme sur un graphe, c'est crétin ; vaut mieux mettre les résultats sur 5 graphes

c'est pas crétin, ça permet juste de faire dire ce que l'on veut à des chiffres bidon

C# 0uwnz D@ W3uRlD ;p

ou pas

les test avec kylix 3 (delphi) athlon 1800+ 512mb
 
Start Delphi benchmark
Int arithmetic elapsed time: 8263ms  
Double arithmetic elapsed time: 23113 ms  
Long arithmetic elapsed time: 23182 ms  
Trig elapsed time: 4170 ms  
IO elapsed time: 6297 ms with max of 1000000
Total Delphi benchmark time: 65025 ms
End Delphi benchmark

 
en effet, c'est une optimisation mais est-ce vraiment une tricheries lorsqu'on regarde toutes les optimisations qui ont été faites pour le c++.net?

 
Paske toi tu benchs les entier 64 bits en utilisant ds flottants ?
T'es un malin toi

qui me dit que les autres compilo ne le font pas en interne?
 
de plus avec python il semble avoir des problèmes avec les long... car il les calcules en 128bits...

 
1/ arrete la fumette
2/ si tu doutes, un coup de disassembly (par ex pour le code de VS)
3/ les resultats ne seraient pas identiques avant/apres optim => optimisation interdite

au faitc'est quoi les superbes optims faites pour VC++.net qui te derangent tant ?

mais en python, y a les int sur 32 bits et les long qui sont infinis. je me tue à vous dire que c'est bancal ce truc. y a qu'a voir le bench python, vu comment c'est écrit, on voit que c'était le premire programme du mec.

il est bien écrit qu'il y a des compilo qui passe de 64bit en 32 bit s'il le peuvent...
 
si c'est pas des optimisations ça...
Java 1.3.1: compiled with javac -g:none -O to exclude debugging information and turn on optimization, ran with java -hotspot to activate the just-in-time compiler within the JVM.
 Java 1.4.2: compiled with javac -g:none to exclude debugging information, ran with java -server to use the slower-starting but faster-running server configuration of the JVM.
 C: compiled with gcc -march=pentium4 -msse2 -mfpmath=sse -O3 -s -mno-cygwin to optimize for my CPU, enable SSE2 extensions for as many math operations as possible, and link to Windows libraries instead of Cygwin libraries.
 Python with and without Psyco: no optimization used. The python -O interpreter flag optimizes Python for fast loading rather than fast performance, so was not used.
 Visual Basic: used "release" configuration, turned on "optimized," turned off "integer overflow checks" within Visual Studio.
 Visual C#: used "release" configuration, turned on "optimize code" within Visual Studio.
 Visual C++: used "release" configuration, turned on "whole program optimization," set "optimization" to "maximize speed," turned on "global optimizations," turned on "enable intrinsic functions," set "favor size or speed" to "favor fast code," set "omit frame pointers" to "yes," set "optimize for processor" to "Pentium 4 and above," set "buffer security check" to "no," set "enable enhanced instruction set" to "SIMD2," and set "optimize for Windows98" to "no" within Visual Studio.
 Visual J#: used "release" configuration, turned on "optimize code," turned off "generate debugging information" within Visual Studio.

Mais ? Désolé de te l'assener comme ca, mais t'es un foutu blaireau ! Quand tu tests le code generé par un compilo, evidemment que tu actives toutes les optims que le compilo autorise, tu voulais quoi ? qu'ils compilent en debug ? Reflechis 2s voyons
 
moi qui pensait qu'il y avait des vieilles magouilles dans le code source special VC.net....

 
oui en mode debug   utilise donc ta cervelle de moineau un peu

 
+1
 
d'ailleurs il pleut de message sur le site de bench que ça vaut pas de la merde...

 
vazy, raconte moi tout

Allez, je viens d'essayer la version CVS de gcc ( la 3.4 ) et j'obtiens des resultats encore meilleurs en calcul entier :
7800 ms pour 32bit
17500 ms pour le 64bit
 
Maintenant, je vais peut-être essayer la branche tree-ssa. Il parrait que ça fait de très bonnes optims le ssa Entre autre, ça peut produire tout seul du code qui parallelise les calculs

 
je cite:
 
le bench sert à déterminer qui sera le plus efficace à effectuer une tache, pas le plus efficace à suivre les spécifications qui sont pas les  
siennes.
 
Un bench d'un langage sert à  
tester la rapidité du langage, pas d'une instruction en particulier. Si un langage X propose 2 façons de faire le même calcul, et si l'une est plus rapide, je vois pas pourquoi, à moins d'être maso, il faudrait choisir la plus lente.

 
très net amélioration, en effet

SSA, c'est une représentation fonctionnelle du programme, je ferais peut-être un paté là-dessus un jour.
 
 
Ce qui me fait marrer c'est que les chantres des effets de bords sont sauvés par une représantation sans effets de bords (d'où la possibilité de beaucoup transformer le graphe).

 
Si un test a pour but de tester la vitesse des opération sur des entiers, et que tu utilises une division de deux réels pour ça, j'appelle pas ça un bon test
D'un autre côté, faut voir comment les autres langages le gèrent...

 
Si monsieur le boulet se donnait la peine de reflechire 2 secondes, il comprendrait que :
- On ne peut *pas* remplacer toutes les divisions sur des entiers 64bits par des operations sur les flottants car les resultats ne sont pas du tout les mêmes. Ces 2 opérations ne sont pas les mêmes c'est tout.
- Rien ne m'empeche de faire pareil en C ou en C++ mais je ne le fait pas car ça fausse les resultats et donc que c'est une mauvaise optim.
 
Si tu ne me crois pas, essaye de calculer 9223372036854775807 / 2 en Int64 et en Double pour voir le resultat

 
en plus il se "croit"  
surement un américain

quels sont les arguments que tu lui opposes ?

 
En tout cas, j'espere que tu ne travailleras jamais sur un compilateur de pret ou de loin.

 
au vu de ses competences je pense pouvoir dire qu'on est peinard

mon cul. C'est typiquement le mec qu'on peut trouver n'importe où. Ces mecs-là on les fait monter dans la hiérarchie rapidement pour qu'il soient moins dangereux.

 
qui a dit que je lui opposait des arguements?
c'est le ton: moi je le pète qui me fait marrer
 
de plus dans ce test ça ne change rien au résultat

 
donc au lieu de repondre a son post intelligent (il avance des faits, lui) par des arguments, tu prefere repondre par des insultes
 
dis, ca t'arrives jamais de te trouver con ? meme juste un petit peu ?
 

 
pourquoi faire un compilo quand il en existe une panoplie?
aucun intérêt valabe
 
t'es surement un mec d'info pour se la péter autant

 
dit ça t'arrive de t'enlever le doigt du cul

 
un autre qui joue du violon, dit si ta pas eu la carrière que tu voulais, c'est pas la faute des autres

 
ouais, pour te repondre, mais finalement je crois que je prefere quand meme le contact de la merde, c'est moins salissant que ta connerie