Reprise du message précédent :

 
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

 
je te l'ai dit clodo ça changait dans le cas présent, lit un peu avant d'insulter tout le monde sans dessin
 
ça t'arrive de penser que t'es l'exemple typique de l'incompétence,  
songe à te mettre un cable autour du coup ou bien le métro

 
allez, la meme en francais
 
t'es sur que t'as compris l'interet d'un bench?

on va y aller pour le québecois:
 
je te l'ai dit crisse de cave, ça change pas pour le tabarnak de cas présent, calisse de morron

 
t'es sur que ta compris l'intérêt de ce bench?

 
ouais, donc t'as rien compris a l'interet d'un bench

 
tester les comportements des langages en fonction de certaines operations.
Par exemple le comportement avec des entier de 64bits.  

 
J'ai trouvé une nouvelle optim pour le calcul d'entiers.
 
Avant :

 
Après :

 
On gagne un temps fou  

sur ce cas, les américains ont trop raison

 
ste vieille remarque a deux balles quand meme

 
si tu crois qu'ils y sont parvenu, tant mieux pour toi

 
c sur qu'avec ton bench a toi qui utilise des float pour faire du calcul entier 64bits, on test achement mieux

un autre bench dans le genre...
http://www.bagley.org/~doug/shootout/craps.shtml

 
un bench ou certain compilo calcul en 32 au lieu de 64.... ça vaut ce que ça vaut
 
qui utilise n'importe quoi pour calculer le temps pour java...
 
les méthodes de io pour vb.net  qu'il a utilisé ne sont même pas les même que celles de c#
 
calcul sur du 128 bits pour python ....
 
en effet c'est un bench vraiment fort...

 
Tu dis ça parceque ton Delphi adoré s'est fait exploser par GCC sous Linux
 
PS : le les entiers longs python ne sont pas en 128 bit. C'est de la precision infinie.
 
PPS : et quel peut bien être ce compilateur qui calcule en 32 bits au lieu de 64 bits ? Delphi ? A non, Delphi calcule en flottant au lieu de 64 bits pardon.

J'ai déconné d'insister pour que antp rouvre ce topic en fait. 3 pages pour rien.

Moi y'a qu'un truc qui me chiffonne vraiment dans cette histoire : java 1.4 est à la rue en calcul trigo, et pas le 1.3. Est-ce qu'on sait d'ou vient la différence ? Du compilo ou de la VM ?

 
VM suremeent, le compilo a pas du bpc changer entre les 2 versions (il effectue de toute facon aucune optim)

'tain, le boulet, j'avais pas compris le bon compilo à la première lecture.
 
 
ça peut aussi venir des fonctions natives qui sont sous le calcul. Comme les fonction des procs Intel sont à la rue, elles ont peut-être été corrigées, ce qui bouffe un temps fou mais permet d'avoir des résultats reproductibles. Il faudrait peut-être faire une fonction non-stricte.

 
je veux voir la premiere version de ton post
 

 
ben c dommage de faire un appel de fonction pour un sinus, quand meme....
 

 
Sisi je suis mort de rire  Je vais bien dormir, mais c'est vrai qu'à part ça, une partie de la discussion n'était pas très instructive    
 
 

1) j'ai lu 2 fois avant de répondre, l'edit ce des fautes d'orthographe.
 
2)

et http://java.sun.com/j2se/1.4.2/doc [...] os(double)
 
ceci dit, ce qu'on voit comme code (kad a fait référence au fait que par défaut c'est StrictMath) n'est pas forcément celui qui est exécuté, c'est le code source de l'implémentation de référence qu'on voit, pas celui du JDK. La différence est subtile, mais dans notre cas ça peut être intéressant de savoir la vérité.

 
ben chai bien, mais par exemple l'appel a sin() en C++ est remplacé par un fin fsin et hoppe
 

Kesdonc que Strictmath? jamais eu l'occas de me plonger dans la machinerie interne de java

Tiens oui d'ailleurs, les résultats obtenus sont-ils les  mêmes avec tous les langages ?

C'est comme Math mais en strict, c'est con comme def, mais ça fait référence à ça :
http://java.sun.com/docs/books/jls [...] tml#249198

C'est la grande question, il faut se tapper toutes les refs et toutes les docs de compilo pour vérifier s'ils font du IEEE ou pas et si les programmes de test ont bien la même sémantique de ce point de vue. Concernant les entiers, il faut vérifier aussi mais c'est plus simple : il n'y a que la taille des mots, signed/unsigned et modularité qui peuvent faire varier le résultat (soit une broutille par rapport à de la virgule flottante).

 
delphi adoré?
c'est pas parce que je fais un site sur le sujet que je l'adole...
 
mis à part une utilisation personnel, je l'utilise pas
 
que delphi se fasse battre par vb, java, python, perl.... ça m'es égale...
 

 
It looks to me like every multiply operation in the long integer test in C overflows 64 bits, so you are benchmarking 1/4 billion 64-bit integer overflows in C (and the others) against 1/4 billion 128-bit integer multiplications in Python, not a fair comparison.
Python is slower but it gives you the correct result!  
 

 
toujours aussi cave

 
By altering the values given to sin, cos, and tan from 0 - trigMax and normalizing then to 0 - 2PI, Java 1.4.2_03 benchmark improves from 57 secs to 10 secs. This change provides a more even distribution of radian values than does the original 0 - 10M. It would seem that the cost of certain radian values for the trig functions is not evenly distributed in java.
 
 
Comparing server VM with client VM is invalid.
He had to put both in both cases.
 
I tested 1.4.2 vs. 1.3.1 (both SUN VMs) and 1.4.2 is 3 times slower than 1.3.1 (they rewrote the VM itself and System.arraycopy() that is being used everywhere got 3x slower).

 
Ce genre de trucs, c'est en MP, faites pas ça en public

 
Je vais pas insisté sur le reste mais je dois au moins corrigé cette grosse bourde :
 

 
C'est pas du 128 bits ça, c'est de la precision infinie. Le gars qui a posté ça sur OSNews n'y connais rien c'est tout.
 
Tiens, en voici un deuxième en cadeau :

 
il utilise combien de bit alors?

c'est dingue, on est en 3ème page et encore entrain de répéter que le bench de python (et tout entier du reste) est complètement bidon car dépourvu de sens

N'exagères pas. Si effectivement il y a un problème de sémantique sur les entiers, il faut corriger le test pour que tout le monde utilise la même sémantique. Par contre, si on peut pas virer l'augementation de la taille des entiers c'est python qui chie et il continue le bench avec son boulet.
 
Mais je serais d'avis de garder 64bits mais en non-modulaire (on s'en branle comment, en exception ou avec des ifs, c'est le pb du mec qui fait le bench) et sans augmentation de capacité.
 
Mais aussi grave, il faudrait voir la virgule flottante, parce que si il y en a qui donnent le bon résultat en 3 plombes pendant que les autres racontent n'importe quoi dans le stress, on compare des approches qui n'ont rien à voir.

jme demande qd meme si ca a bcp de sens avec les optimisation faites par le compilo  
 
un exemple  

 
 
Après :  

 
 
bon jvois pas pq le compilateur ne le ferai pas tout seul ce genre de truc
 
par exemple jai deja remarque quil me faisait ca :
 

ben ca sera remplace par  

 
lors de la compil (vu sous win32dasm apres avoir decompile le prog)
 
bon ca cetait uniquement en release et parce que le nb passé a la fonction etait connu a lavance
 
pq y ferait pas ca pour le bench ?

toujours pour parler de python mais surtout de la qualité des codes : parce que ne pas connaître les idiomes d'un langage ne permet d'écrire un programme correcte pour un benchmark. parce que ce bench outre les résultats des autres langages que je conteste, il descend surtout python. ok python est pas dans son élément pour ce genre de calcul intensif (on ne saurait lui reprocher) mais y aussi la manière de coder qui compte.
 
en C on a  
 
int i = 0;
while (i++ < ioMax)
{
 fputs("abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh\n", stream);
}
 
mais en python on se prends dans la tête un
 
for i in range(ioMax - 1):
        linesToWrite.append(myString)
    file.writelines(linesToWrite)
 
 
autrement dit pour écrire ioMax fois la même ligne, une seule et même grande ligne est constituée, cequi est très long vu la longueur et la nature immuable des chaines en python. mais non, c'était trop facil de faire comme en C (une boucle qui écrit ioMax fois la chaine) voir meme de faire la manière python myString*(ioMax-1)
 
et d'ailleurs file est une fonction builtin en python, ici écrasé ... ça en dit long
 
et puis ça un petit cours de python cette réponse en plus

hop : j'ai fait un petit article pour les entiers et montrer un peu pourquoi python traine son boulet sur les overflows : http://www.nraynaud.org/wiki/NombresEntiers
 
n'hésitez pas à éditer et commenter, c'est un wiki.

j'ai pas compris le coup de l'overflow ?

Il y a beaucoup de bruit autour de l'aspect BigInt de python qu'il ne serait pas cool de comparer avec les autres langages. Donc j'explique un peu tout ça dans mon article.
 
 
Pour rentrer dans le troll, si vraiment les bigInt c'est pas bien, ils n'avaient qu'à pas le mettre par défaut dans le langage.
 
Quan au fait que le bench dans tel langage est boulettisé etc. Je rappellerais simplement que la programmation est un domaine de boulets et qu'il a fait exactement ce qu'on trouve dans la nature : des merdes dans tous les sens, donc les bench sont beaucoup plus proche de la réalité que ce que certains voudraient faire croire (probablement ceux qui voudraient voir leur langage en première place, passke plus c'est vite et plus ça vend au pays des boulets).

1) donc y a pas de problèmes d'overflow. un int est un int, un long est un long.
2) les long de python sont soigneusement implémentés
 
moi je vois pas de boulet. les int sont sur 32 bits, après les long sont infinis. tester 64 bits est idiot puisqu'il n'y a pas d'équivalent au long long du C.
 
je comprends pas toujours pas ta réflexion ... je vois pas de boulet, c'est normal. y a qu'a passé tout les benchs 64bits avec des BigInt, quelque soit le langage on sera a des années lumières.
 
note encore une fois que le test est maladroit en python, puisque les int sont automatiquement promu en long si nécessaire, donc commencé le calcul en long est pénalisant. autant ne pas s'en soucier
 
 
edit: en fait j'arrive pas à comprendre si tu reproches le fait qu'il y ait des bigint ou si tu trouves ça bien.

J'en ai rien à foutre.
 
J'essaye de faire des remarques constructives, pas de faire un débat binaire et de considérer que mon langage préféré a été mal testé, passke sinon il serait premier.
 
J'ai plaidé pour la rouverture de ce topic et j'ai eu tord : rien d'intéressant n'en sort, toujours les conneries "on compare pas la même chose", "ils ont été méchant avec mon langage" et la présence d'os2.
 
Ce bench je le prends comme ça : qu'est-ce que monsieur boulet peut attendre de chaque langage en perf ? Et monsieur boulet il passe sa vie à concaténer des chaines, il sait pas ce qu'est un bigInt (peut-être même ne sait-il pas qu'une multiplication double le nombre de bits nécessaire pour stocker le résultat), il ne sait pas ce qu'est la norme IEEE754 (et il s'en fout), il compare ses nombres en virgule flottante en regardant si la distance entre les 2 est inférieure à epsilon (parce que ça marchait pas et qu'il a vu sur un forum qu'il fallait faire ça), il utilise des étoiles partout en C++ et n'a aucune idée de ce qu'est un template. Il n'a aucune idée de comment fonctionnne un GC et de comment limiter la pression dessus.