Reprise du message précédent :
Enfin en meme temps, et vu que ca ne change rien au debat, pour AMD, ca ne change pas grand chose. La puce fait toujours ses 315 mm2, elle chauffe toujours autant, etc etc.
 
En fait, la marge de rogression, elle devrait surtout venir de la gravure.

Ils vont pas dire qu'il y a 1,8 milliards dans un FX-8xxx quand la puce performe moins qu'un i7 2600 qui peine à dépasser 1,2 milliards
C'est tout

mais je comprend pas c'est bien amd qui a fait le cpu?

Non, c'est une IA qui tournait sur des Xeons

 
 
Mais bon, vu les performances, c'est à se demander

Ah bon, et ca changerais quoi ?

On nous a expliqué que ce qui a limité la montée en fréquence et qui explique la forte consommation de Zambezi, que c'était dû aux 2Md de transistors alors que SB en avait environ 2 fois moins. Mais cela soulevait interrogation : comment Intel a réussit à faire aussi bien que Zambezi avec 2 fois moins de transistors (tout en intégrant un IGP) ?
Aujourd'hui on nous dit que Zambezi à un nombre de transistors similaire à SB 4C. Beaucoup d'explications et de questions deviennent donc caduques, mais en soulèvent d'autres. Je trouve au contraire cela très intéressant et mériterait plus d'investigation de la part des spécialistes pour assouvir notre curiosité et notre soif de connaissance.

Pour les simples consommateurs (que nous ne sommes visiblement pas puisque très peu d'entre nous est intéressé par l'achat d'un Zambezi) effectivement, ça ne changera rien au résultat final. Mais ça n'empêche pas à certains d'entre eux et à beaucoup d'autres d'être curieux, de comprendre et d'en savoir plus sur toutes ces bestioles technologiques

Pendant ce temps AMD a d'autres chats à fouetter.  
 
http://www.developpez.com/actu/396 [...] gle-Intel/
 
 

Qu'ils sont nuls.
De rien

Vendredi ? Ah non on me dit que l'on est Mercredi

Bah ouais, besoin d'être vendredi ?
+50% de transistors, +50% de conso, +50% de taille de puce, -100% de rentrées dans les caisses.
Vaut mieux dire qu'il y a à peu près le même nombre de transistors si on veut pas passer pour des buses...

 
Effectivement, c'est bien dit. Mais attention:
- Plus de transistors ne limitent pas forcement la vitesse pure.
- La conso devient effectivement plus difficile a accepter.
- La densite du 32nm GF qui etait sense etre excellente semble se reveler tres mauvaise, etrange, et surtout dommage car on a certainement fait un choix sur le ratio taille transistor/performance.
 

La aussi, c'est bien resume.
 

Je ne parlais meme pas du point de vue des clients, mais d'AMD.
La taille du bulldo est toujours gigantesque, donc a ce niveau, il n'y a pas vraiment de marge de manoeuvre.
En fait, je crois que beaucoup de choses sont liees a Glofo et ses ameliorations attendus pour bientot.

Et tout comme la course à la fréquence des années 90, Bulldozer montre que la course au "Coeur" n'est pas non plus la solution à la performance
 

GrosFlop attend des améliorations bientôt ?      
 
2012 l'année de la fin du monde et de E.T. qui arrive pour sauver GrosFlop et renouveler son forfait 3G pour "téléphone maiiiiison"
 
 
mince on est pas vendredi  

dévellope, je n'ai pas compris.

Alors là non On ne devrait plus entendre ça !
Bordel je sais pas ce qu'il te faut ! le SB-E fait bien plus péter les chiffre avec ses +2.2 milliards de transistor et 435 mm² de surface !
Ah mais chui con vu qu'il est perf et que c'est untel, on pardonne tout a ce gros perfo de CPU !
Même d'être gros, chaud, power-drower et cher

Oui mais c'est un huit coeur... wait

Hé Hé

huit Wirmish-core

Le choix de GloFo Gate first ou last, j'arrive jamais à retenir, un des éléments avancés était d'avoir une très bonne densité.
Il ne faut pas se leurrer, c'était bien vouloir avantager la densité au dépends d'autres charactéristiques.
 

Je me mettais au niveau d'AMD (parler de taille de die, c'est bien se mettre à la place des compagnies, pas du client) et là, une puce de 315mm² est une ABERRATION.
Quand on traine en perf derrière un numéro 1 solidement en place, on parie tout sur des bas tarifs ET on essaye d'avoir des produits à faible coût de revient.
Ou alors on sort un gros monstre, qui marche du feu de dieu.

Il me semble que la densité c'était du blabla sans fondement, par contre le gros argument était le process flow non modifié, entraînant un coût moindre.

En fait, on ne sait toujours pas si le Gate First est au point sur la variabilité des gates justement, qui était le handicap dès le départ.

Exactement ce qui s'était passé avec Hammer (performant voire très performant, au prix d'une conso sensiblement plus élevée que les P3 concurrents)... c'est marrant quand on y pense.

Ecoute, t'est pas le premier a remettre en doute cette histoire de densité, et les faits semblent te donner raison donc ...  

Oui, enfin, AMD savait qu'ils avqaent parmis eux plusieurs des meilleurs inges disponible sur le marche.
Depuis quelques temps, apparement, dès que tu est bon, tu te fait lourder.

 
Mieux vaut tard que jamais, depuis le temps qu'on te dit que GloFo est charrette, tu commences à comprendre ...    

Effectivement, je prefere attendre des elements tangibles    
 
Et je rmet 2 euros dans la question de compilateurs:
http://semiaccurate.com/forums/sho [...] tcount=184
 

Avant que quelqu'un fasse une remarque, c'est Hans de Vries qui a ecris ce post.

les meilleurs ingés, certes oui, mais en CPU Desktop
et vu qu'AMD veut faire du VIA/ARM/APU

et bien AMD va devenir un VIA² avec 3% de PDM !  

J'ai bien utilise le passe, je parlait de la situation d'AMD au moment de la faillite de DEC.

t'inquiète pas j'ai utilisé le présent, parceque c'est ce qu'ils font, "présentemment"

 
 
troublant...

Trop d'ecart pour qu'ils n'y ai pas de feinte genre du FMA utilisé dans le Open64 et pas dans le Intel ou des trucs du genre...
 
En plus faudrait comparé le code Open64 et Intel aussi sur les Sandy Bridge... Parce que si Open64 sur ce code reste meilleur qu'Intel ça ne prouverais rien.

indubitablement

http://www.anandtech.com/show/5183 [...] os-testing
 
Interressant.

Pas si simple...
 
Un FX8150 en turbo ça fait 3.9ghz alors qu'un opteron 6282 SE ça fait 3.1ghz donc les scores avec les vrais fréquences (et ceux du i7 2600k) sont :
 
FX8150 (windows icc) @3.9ghz 115 / 79.6
i7-2600k(windows icc) @3.5ghz 166 / 113
i7-2600k (redhat icc) @3.5ghz 170 / 122
opteron (redhat open64) @3.1ghz 134 / 100
 
Selon Intel le fx8150 est à 70% du 2600 (mouarf)
Selon Open64 le 8150 est à 100% du 2600 (la vérité vrai)
Selon hardware.fr le 8150 est à 88% du 2600 (au pifomètre entre les deux, évidement)
 

pfff anandtech qui teste un processeur AMD c'est la même chose qu'un test spec.org du bulldozer sponsorisé par Intel  
 
Moi j'aimerais bien savoir pourquoi dans tous les benchs standards (spec, vmmark, sap, tpc) les nouveaux opteron 6200 sont loin devant les vieux xeon, mais pas chez anandtech.

Rien ne change.
Entre la vérité vrai d'AMD et son complio et le pifomètre d'HFR, c'est un dredÿ qui commence sur les chapeaux de roues

Open64 + SPEC_int_rate = la vérité vraie ?
Ne pas oublier qu'HFR a testé des CPU desktop dans un panel applicatif desktop et leur vérité est à mon avis plutôt proche de la réalité.
Concernant ces résultats, à mon avis la vérité est ailleurs...

Ah, oui, ca, ca risque fort. Enfin, si utiliser correctement un bulldo c'est un feinte .....

Tu peux me montrer cesfameux benchs chez Anandtech ?

 
Ouai enfin là direct on parle de suspision de cheat du compilo Intel voir même de toutes les compilateurs du monde sauf Open64, forcement...
 
En plus bon le FMA c'est bien gentil, mais c'est pas exploitable sur un très gros pourcentage d'applications hein... C'est pas ça qui va te faire tourner Word, Winamp ou Battlefield 3 plus vite quoi...
 

Ce qui est intéressant c'est delta important entre le SPECint®_rate2006 et le SPECint_rate_base2006 sur l'Opteron avec Open64 : 15% c'est énorme. Du coup en base on est à 146 pour le "FX" vs 164 sur l'i7, mince on retombe sur 89%

Rappel :

Si on compare les résultats de l'i7-2600K RedHat ICC à le FX simulé à partir de l'Opteron (division par nombre de coeur, rajout du déficit de fréquence) on a pour l'i7 avec le "FX" en base 100 :

En Peak :

116,9 400.perlbench
96,2 401.bzip2
103,7 403.gcc
58,7 429.mcf
111,8 445.gobmk
90,2 456.hmmer
125,8 458.sjeng
114,9 462.libquantum
149,7 464.h264ref
86,3 471.omnetpp
81,0 473.astar
103,1 483.xalancbmk

Le FX est devant sous 5 bench sur 12, et il creuse un écart de fou sous 429.mcf. A contrario l'i7 est bien plus rapide sous 464.h264ref

En Base :

121,3 400.perlbench
96,1 401.bzip2
118,7 403.gcc
107,2 429.mcf
121,1 445.gobmk
86,6 456.hmmer
134,4 458.sjeng
118,5 462.libquantum
170,4 464.h264ref
83,9 471.omnetpp
97,7 473.astar
106,4 483.xalancbmk

Le FX est devant sous 5 bench sur 12. Cette fois c'est plus compliqué pour le FX, il est même dépassé sous 429.mcf, les optimisations spécifiques en peak apportant un gain de 82.5% ce qui est énorme.

Mais bon comparer au % près à de grosses limites.

- D'une part, on ne sait pas quelles sont les fréquences réelles employées au fil du bench du fait du Turbo qui peut varier
- D'autre part, sur 8 coeurs est obtenu en divisant bêtement par 4 le score d'un serveur en 32 coeurs. D'une le scaling des différents benchs n'est pas forcément parfait, ce qui fait que la division par 4 serait abusive, mais dans l'autre sens on a une architecture qui diffère en terme de bande passante avec par exemple de la mémoire sur 4 canal pour chaque Socket. C'est pas vraiment du apple to apple.

AMHA on peut surtout voir de tout ceci que le score rentré par Intel pour le FX sous ICC est douteux. D'ailleurs il n'y a pas besoin de regarder les résultats de Dell sous Open64 ou de Intel sur un de ses CPU pour le voir, Intel a également rentré un score pour le Phenom II X6 1100T. Le X6 est 1-3% plus rapide en INT, 9% plus rapide en FP.

Reste qu'effectivement, pour gérer tes bus tigredubois, le FX avec Open64 risque de déchirer des slips (ça c'est gratuit )