Istanbul vs Nehalem sur LINPACK: http://www.advancedclustering.com/co...eron-2400.html
Istanbul vs Nehalem sur LINPACK: http://www.advancedclustering.com/co...eron-2400.html
Mmmh, pas mal, l'efficacité d'Istambul n'est "que" de 7 points en deçà de Nehalem.
Ils n'ont pas inclus la conso de la plateforme par contre, et là Intel avec son process et seulement 4 cores doit être bien devant. Ca peut influer sur le ratio $ / GFLOP, même si 15$, ca parait assez difficile à rattraper (pour du quad vs hexa).
Attention quand meme : la lib math kernel d'Intel a ete grandement optimisee pour i7 assez recemment. Donc selon la version qu'ils ont utilisee pour leur benchmark, ca pourrait changer les resultats de maniere assez radicale.
C'est normal, les Xeon ont un TDP inférieur à leur équivalent desktop [80W contre 95], ils doivent être sélectionnés beaucoup plus rigoureusement, un peu comme les extrem [et Athlon FX], voilà ce qui rends les CPU pour serveurs beaucoup plus chers, avec aussi le fait qu'ils doivent s'acheter en beaucoup moins grosse quantité vue le faible taux d'acheteurs.
http://www.hardware.fr/news/10392/12...ous-cpu-z.html
J'imagine que les 10 Mo de L3, c'est parce que l'HT-Assist bouffe 1 Mo par die.
Hum sur Shanghai c'est 48-way, donc logiquement c'est pareil sur Istanbul et ça passe à 96 sur Magny-Cours, mais effectivement s'il ne détecte que 10 Mo c'est étonnant.
Effectivement. Vu que c'est une config mono-socket, double-die, il ne devrait pas y avoir besoin de probe filter et donc le/les L3 devraient bien faire 12 Mo avec 96 voies.
Et en multi-socket (>=2?) on devrait avoir 10 Mo avec 80 voies...
Probablement un problème de bios ou de détection...
Non c'est du dual-socket, cf. Le reste ici : http://www.xtremesystems.org/forums/...d.php?t=233565
Du coup ça fait 4 dies donc il est logique que l'HT-Assist soit activé.
Je boycotte Intel et sa valse des sockets.
Pour le 64-bit chez AMD, je ne suis qu'à moitié étonné : ils ont fait un vrai effort, pas comme les "autres" qui n'ont été que des suiveurs sur ce coup-là, alourdis par un souci initial de schyzophrénie itanesque.
Tu risques de boycotter un moment. De toutes facons on a deja eu cette conversation, ce n'est pas comme si tu allais upgrader ton CPU sans changer la carte mere . C'est pour le principe !
---------- Post ajouté à 01h53 ----------
Oui, les ameliorations dans le frontend de Nehalem deviennent visible avec le passage au 64 bits. Le fait que le passage au 64bits se soit fait si tard a serieusement desavantage AMD qui avait une archi efficace sur du code 64bits depuis longtemps...
Ca me rappelle un peu la sortie du PPRO, qui n'etait pas vraiment mieux que le pentium sur du code 16 bits. Tout le monde achetait du pentium jusqu'au jour ou le code 32 bits a pris le dessus. Pareil pour core2/corei7, avec le passage au 64 bits, les offre core2 vont commencer a se faire vieille...s
fefe - Dillon Y'Bon
http://www.semiaccurate.com/2010/02/...nm-llano-core/
Toujours pas de grosse amélioration du core (K10 based en gros)... dommage.
Ca n'aurait pas été casse-gueule de faire à la fois l'intégration du GPU et le changement de process et de gros changements de micro-architecture en une fois ?
C'est pas comme si le core n'avait pas ete touche. Changer la taille des buffers force toujours a pas mal de changements locaux pour maintenir tes timings, un meilleur diviseur est un bout de hardware pas particulierement simple. En gros ce qui est decrit la est l'equivalent du passage de Merom a Penryn, voir meme un peu plus. Des fois il n'y a pas besoin de changer la micro architecture quand tu peux juste corriger toutes les petites inefficacites du projet precedent.
fefe - Dillon Y'Bon
Et puis la latence des instructions FP aurait été réduite, ce qui suivant de quelles instructions on parle peut être un changement conséquent...
Même si je vois mal AMD faire des modifs importantes à une FPU qui n'a quasiment pas changé depuis 10 ans, alors qu'une version totalement nouvelle pour Bulldozer est dans les cartons.
À moins que ce soit justement à titre expérimental pour avoir un retour avant Bulldozer, mais ça serait un peu risqué pour une expérience...
Ca peut etre pour les instructions microcodees qui peuvent maintenant utiliser la logique du divider et devaient utiliser des rounds de mul-add avant. C'est ce sur quoi je parierais.
fefe - Dillon Y'Bon
Du genre, la division/racine carrée flottante qui utiliserait le diviseur matériel pour avoir une meilleure approximation initiale et faire moins d'itérations? Ou bien carrément un diviseur hardware complet?
Récemment on a aussi vu passer des papiers de gens sponsorisés par AMD sur l'utilisation d'une unité dédiée d'élévation au carré (de latence largement inférieure à celle d'un multiplieur) pour accélérer la division par convergence...
Dernière modification par Møgluglu ; 11/02/2010 à 21h44.
Il semble que la livraison des opterons "Magny-Cours" a débuté .
De 1,5 à 2,4 Ghz en octocore et de 1,9 à 2,2 Ghz en dodécacore ,tous avec 12Mo de L3 et 115W de TDP .
Et un controleur DDR3 sur 4 canaux (nouveau socket) ,à voir au niveau perf en multi s'il y a eu d'autre amélioration au niveau archi
Edit : confirmation sur le blog AMD
Dernière modification par Lionel33 ; 23/02/2010 à 14h21.