En parlant de crypto : http://blogs.sun.com/bmseer/entry/ul...ography_on_the
Attention ça vient de Sun, mais ça ne montre vraiment pas les x86 sous un beau jour, et je ne pense pas que ça ait grandement évolué depuis.
En parlant de crypto : http://blogs.sun.com/bmseer/entry/ul...ography_on_the
Attention ça vient de Sun, mais ça ne montre vraiment pas les x86 sous un beau jour, et je ne pense pas que ça ait grandement évolué depuis.
Quand je vois ce tableau je me demande surtout pourquoi il y a autant de difference entre les differents chips. Je vois des "accelerator cards" 8x plus lentes que le xeon sur AES, un opteron a peu pres aussi rapide que le xeon (1/2 la vitesse a 1/2 core count).
Sur RSA l'Opteron et le xeon sont a peu pres equivalents encore une fois (j'arrondis a la louche), mais quand je vois un 32 core power 4 (certes a 40% de la frequence) qui fait moins qu'un octo Xeon je commence a me poser des questions sur la methodologie...
Bref ca ressemble a une jolie pub pour Niagara et Rock, mais si on considere les perfs de ces chips par rapport a la competition sur la majorite de ce que les serveurs executent on peut se demander pourquoi c'est si rose dans ce test ( ca me rappelle un test spec ou les SPARC eclataient tout le monde parce que le compilo sun detectait une boucle specifique et faisait une inversion de boucle pour que tout tienne dans les caches oui, ils changeaient le bench, mais ca c'etait vu parce que spec etait utilise par un peu plus qu'eux).
Bref ca serait interressant de comprendre quels sont les arguments pour expliquer de tels ameliorations par rapport a leurs 3 concurrents principaux.
A partir du moment ou quelqu'un d'exterieur reussit a reproduire des resultats similaires je serai pret a l'accepter un peu plus facilement .Benchmark Description
The RSA/AES-128 Cryptography benchmark was developed by Sun to measure maximum throughput of RSA private key (sign) operations and AES-128 operations that a system can perform.
Anandtech a un article ou un octo opteron qui bat le T2000 sur openssl (Opteron qui va a la meme vitesse qu un xeon woodecrest a iso cores). Hyperthreading aide probablement ainsi que le nombre de cores par socket donc les machines Nehalem doivent avoir progresse pas mal aussi. (http://www.anandtech.com/IT/showdoc.aspx?i=2772&p=5)
Donc avant de dire que Sun est le plus rapide pour la crypto et que ca n'a pas du changer depuis 2007, je pense qu'il y a pas mal de verifications a faire . Je ne doute aps du fait qu'ils soient competitifs, mais quand je vois des graphes montrant un constructeur 4x meilleur que le reste du monde mon detecteur a marketing bs passe au rouge.
fefe - Dillon Y'Bon
Tu veux dire que tu t'attendrais a voir un Opteron et un Xeon avoir la meme perf sur RSA ?
http://gmplib.org/gmpbench.html
rsa K10 3.2 GHz : 5226
rsa i7 920 2.67 GHz: 3284
En ramenant a la frequence ca ferait 3935 pour le i7. Et c'est en ligne avec tous les autres resultats multi-precision que je connais qui utilisent la widening mul 64 -> 128 (GIMP factor par exemple).
Mais si tu veux plutot dire que d'apres la page un Xeon a a peu pres la meme vitesse qu'un Opteron sur RSA, alors oui, c'est n'importe quoi
Et y'a aussi l'histoire du autopar, breche que tout le monde a fini par tenter d'utiliser( ca me rappelle un test spec ou les SPARC eclataient tout le monde parce que le compilo sun detectait une boucle specifique et faisait une inversion de boucle pour que tout tienne dans les caches oui, ils changeaient le bench, mais ca c'etait vu parce que spec etait utilise par un peu plus qu'eux).
100% d'accord ! Mais il faut avoir acces aux machines, et du temps pour tuner le code au mieux, sinon ca aurait peu d'interet.A partir du moment ou quelqu'un d'exterieur reussit a reproduire des resultats similaires je serai pret a l'accepter un peu plus facilement .
Ce n'est pas la meme generation de SPARC non plus, entre le blog que j'ai linke et le T1 d'Anand : T2 1.4 GHz vs T1 1 GHz.Anandtech a un article ou un octo opteron qui bat le T2000 sur openssl (Opteron qui va a la meme vitesse qu un xeon woodecrest a iso cores). Hyperthreading aide probablement ainsi que le nombre de cores par socket donc les machines Nehalem doivent avoir progresse pas mal aussi. (http://www.anandtech.com/IT/showdoc.aspx?i=2772&p=5)
Comme tu dis il faudrait un truc plus a jour ; mais je doute que sur RSA le progres pour Nehalem soit enorme ; d'apres le bench GMP ca fait moins de 10% pour Core2 vs Nehalem (a prendre avec des pincettes, il faudrait voir le niveau d'optim fait pour i7).
J'avoue que poster ce lien etait assez peu judicieux, mais je n'ai rien trouve d'autre...Donc avant de dire que Sun est le plus rapide pour la crypto et que ca n'a pas du changer depuis 2007, je pense qu'il y a pas mal de verifications a faire . Je ne doute aps du fait qu'ils soient competitifs, mais quand je vois des graphes montrant un constructeur 4x meilleur que le reste du monde mon detecteur a marketing bs passe au rouge.
Option 2, je cherchais a exposer le fait que la relation entre tous les processeurs non Sun sur ce bench etait n'importe quoi => ce bench = n'importe quoi...
Sur I7 je doute que tu aies plus de 10-15% par thread. En revanche tu as 8 threads par socket au lieu de 2-4 sur les generations precedentes, et ca va te donner un boost significatif.
Et y'a aussi l'histoire du autopar, breche que tout le monde a fini par tenter d'utiliser
100% d'accord ! Mais il faut avoir acces aux machines, et du temps pour tuner le code au mieux, sinon ca aurait peu d'interet.
Ce n'est pas la meme generation de SPARC non plus, entre le blog que j'ai linke et le T1 d'Anand : T2 1.4 GHz vs T1 1 GHz.
Comme tu dis il faudrait un truc plus a jour ; mais je doute que sur RSA le progres pour Nehalem soit enorme ; d'apres le bench GMP ca fait moins de 10% pour Core2 vs Nehalem (a prendre avec des pincettes, il faudrait voir le niveau d'optim fait pour i7).
Je n'ai rien trouve d'autre non plus en googlant un peu, a part 3-4 data points qui montraient que ce bench etait foireux. A quand un site de test qui fait du benchmarking serieux sur la crypto, et qui ne s'arrete pas aux X86? (Hint-hint).J'avoue que poster ce lien etait assez peu judicieux, mais je n'ai rien trouve d'autre...
PS: Si tu compares des benchs avec un i7 et que tu comptes scaler pour la frequence, il te faut mesurer la frequence d'operation et non la frequence TDP. Sur les premiers i7 avec peu de turbo range, tu n'es jamais tres loin de la frequence TDP, mais sur les plus recents avec une bonne turbo range, tu es rarement proche de TDP, sur des applis a faible IPC tu en es meme tres loin. Donc ton i7 a 2.6 tournait probablement a 2.9 ou 3 sur ce bench (donc pas la peine de scaler le score avec la frequence).
La frequence TDP = la frequence la plus basse a laquelle le processeur peut tourner en operations normales = la frequence a laquelle il tournera sur l'application la plus gourmande ~= sur i7 la frequence a laquelle 8 copies de prime ou linpack tourneront. Vu que peu d'applis consomment autant que ca, la frequence d'operation de ces autres applis sera plus elevee. Elle est meme calculable. Si tu connais le ratio de power (lie au facteuer d'activite) a une frequence donnee entre ton appli et linpack, il te suffit de calculer F = P TDP/(ACV^2) pour trouver la frequence a laquelle tu opereras (c'est un peu plus complique que ca dans la vraie vie mais bon ). La version rule of thumb est si je consomme x% power en moins, je peux avoir x%/3< Frequence en plus <x%/5, plus ton voltage de base est haut plus tu seras pres de x%/5.
Dernière modification par fefe ; 17/02/2010 à 15h30.
fefe - Dillon Y'Bon
Moi aussi : j'ai decide de ne plus perdre mon temps libre avec de l'ARM (serieux).
En fait j'aimerais bien avoir du temps pour des petits projets perso. Mais bon ca ne serait probablement pas du benchmarking, ca serait plutot construire un APN a partir d'une chambre, d'un scanner et d'un iphone (tiens de l'ARM !!!)
fefe - Dillon Y'Bon
C'est normal que ce fichier :
Intel® Core™ i7-900 Desktop Processor Extreme Edition Series and Intel® Core™ i7-900 Desktop Processor Series on 32-nm Process Specification Update
http://download.intel.com/design/pro...pdt/320836.pdf
soit protege par un mot de passe ? Il me semblait que les errata etaient librement dispos.
Mouhaha ils doivent filtrer ce qui vient de chez certains domaines, c'est mesquin