Reprise du message précédent :

Ce n'est pas forcément un problème que le thread saute de core en core, il n'y a pas forcément d'impact notable sur les perfs (en tout cas moins que ce qu'on pourrait croire)

En tout cas pour voir un Turbo c'est tjs mieux de fixer l'affinité, ça permet de mieux visualiser la fréquence atteinte vu la relative lenteur (tout est relatif) des monitorings, encore que Tmonitor va vite et a une fonction de log.

négligeable : j'avais une fois fait le test avec CPUMark99 et 2 pts de différence sur un score qui dépassait 500 !

26.618 sans régler l'affinité, 26.713 au SPI 1M en la réglant sur un K10.5... Négligeable, quoi (et heureusement limite )

Si l'impact n'était pas à la marge le scheduler ne fonctionnerait pas ainsi, quoi qu'en disent les anti microsoft

Ca dépend grandement des cas, mais il faut quand même reconnaître qu'un thread qui tourne seul n'a pas à se balader de core en core
 
Après, il y a souvent d'autres goulets d'étranglement que la purge des caches, SuperPi est par exemple pas mal impacté par le disque sur lequel il colle ses données de sortie (tu peux essayer sur une clé USB "lambda" pour le voir... sur mon E-350 c'était quelque chose comme un temps allant du simple au triple).

 
Tu peux pas nous donner des chiffres sur tout ça, le temps perdu ns précisement, Quel est le déclencheur du changement
de core etc..... c'est interessant  
 
je ne trouve pas de screen température des cores Bulldozer

à première vue j'avais pensé 24Mo (12Mo L2 & 12Mo L3). Mais en fait il en aurait plutôt 28Mo (12Mo L2 & 16Mo L3).
Ça reste une simple étude, rien sur sa faisabilité ni son rendement et encore moins sur les données en évolution.

Regarde pas les MCM d'IBM alors, certains Chip ont 40Mo de cache, pour un niveau, minimum

 
Bon, bah ayant essayé sur une clé USB 4 Go minable signée A*D, je met 1:04 au SPI 1M rien que les 3 premières itérations...
 
Et 38.862 s au 64K

Malheureusement non, et de toute façon aucun outil n'est assez précis pour mesurer le temps perdu, outre le fameux phénomène de l'influence inévitable de l'observateur sur ce qu'il observe.

Je me demande aussi ce qui peut provoquer le changement de core, la logique voulant qu'un thread "monopolisant" un core se fasse attribuer la priorité maximale sur ce core.

Edit: en me relisant, j'ai réalisé que le changement pouvait éventuellement coïncider avec le transfert d'une zone mémoire du thread en question vers un pilote.

Juste une précision en passant, que j'avais posté sur le forum cpc (copier/coller powa) :
 
Ceci dit, vu les spécificités de cette architecture, on peut clairement faire dire ce qu'on veut aux benchmarks. En fonction des benchs qu'on sélectionne, on aura des performances diamétralement opposées. Prenez SuperPi, vous aurez des perfs épouvantables, avec un FX-8150 en dessous d'un Core 2 E6700 de 2006. Prenez WPrime32, vous aurez un FX-8150 devant un Core i7 2600K. Et c'est pareil dans tous les types d'applications. Bref, c'est un cauchemar à tester ce processeur.
 
C'est un point vraiment fondamental lors des tests qui vont sortir. Ma seule crainte, ce n'est pas une hypothétique version B2-H²'++ qui n'existe que dans les délires de JF-AMD ou un AGESA de la mort qui rajoute 50% de perfs, ou un BIOS of the dead qui débloque le cache L2, c'est surtout de ne pas avoir choisi la bonne suite de benchmarks pour être représentatif. J'ai viré tout ce qui avantageait trop AMD ou Intel, tout comme on vire généralement les Batman et autres des tests GPU. Mais bon. Si il n'y avait pas eu le NDA, j'aurais publié tous les benchs séparément pour une fois, plutot que de faire une moyenne, mais la, ca aurait fait "perdre" trop de pages.  
 
PS : Les tests de power ont été fait sous Linpack.

c'est toi qu'est B2-H²'++

1/ Nan mais là, + 1000000 au moins

Les perfs ont l'air super variables. Un bon wPrime, un mauvais Cinebench, quelques bons x264, des mauvais jeux, etc...

Comment l’interpréter alors ?

Moi je dis, faut prendre du "représentatif", puis basta. Ça l'arrange tant mieux, sinon... Mais c'est vrai que c'est pas top, ça. Nouvent concept powa'...

Peut être une amélioration dès que ça sera optimisé pour ? A voir... Mais on serait ptet dans le cas K10. En pire... C'est à dire le Phenom meilleur que le A64 X2 dans certains benchs, devant dans d'autres...

2/ Pas mal les délires à la JF. Faudrait qu'il nous dise il fume quoi...

Attends, 50% de plus l'AGESA, c'est moi ça

3/ 18 cycles non ?
Mais tu n'as pas de NDA pourtant

une news je sais pas si cela a ete relater.....
 
http://www.presence-pc.com/actuali [...] tor=RSS-11

 
Aurais tu un screen des températures Cpu et cores Bulldozer ?    
 
Merci par avance    

 
Comme un CPU qui va nécessiter BEAUCOUP de travail côté développeurs et compilateurs pour pouvoir être exploité correctement. Dans le passé, ça n'est jamais arrivé. Je suis curieux de voir si un testeur va oser publier un Linpack ou un Spec à la sortie du FX...

Ouais, ce qui fait peur, c'est est-ce que AMD sera assez influent pour imposer le concept (et ça peut être intéressant après tout...), ou alors, ils sont dans la merde. C'est du nouveau concept quand même, une beta quasiment...

 
Ne pas le faire c'est mentir a ses lecteurs si c'est un point faible    
 

je pense que la meilleure solution serait de tester un maximum de logiciels

 
Ouais, mais représentatifs alors
 
Vas pas tester du Crysis sur un Opteron, ou je ne sais quoi sur un FX

c'est quoi ce truc ?
 
http://1.bp.blogspot.com/-nBjED8GQ [...] no_die.jpg

Llano ?

En fait, je pensais à un truc. Depuis le X6, AMD met dans ses noms de révision le nom du processeur.

PH-E0

LN1-B0

Pourquoi pas "OR-B2" au final...

Le schéma de la page 44 est-il exact au final? L'exécution des threads est-elle entrelacée au sein du module comme ce schéma l'indique (amenant le double de ressources dans le cas où on exécute qu'un thread sur le module), ou non?

 
Linpack est un bench orienté pour être un bench, c'est à dire pour exploiter au maximum les détails de l'architecture. Linpack avec un cache L1 de 16K, ça ne peut pas fonctionner. Je n'ai pas réussi à le faire fonctionner en AVX sur Bulldozer, mais en SSE, les résultats étaient épouvantables. Pourtant le SSE, ce n'est pas de l'INT, c'est bien traité par le fameux FlexFP. On peut dire que Linpack est un bench, qu'il n'est pas codé pour tirer parti de l'architecture de Bulldozer, et c'est parfaitement vrai. Mais est-ce représentatif d'une "vrai" appli ou pas ? La est la question.

 
Non. Le schéma la, c'est celui de l'Alpha. Et c'est la tout le probleme. Selon moi (mode subjectif, mais basé tout de même sur des sources internes), c'est ce qu'AMD a cherché à faire dans Bulldozer. MAIS, pour une raison ou une autre, même si le hardware est la, il ne fonctionne pas en pratique. C'est pourquoi on a vu les projections d'AMD en termes de performances s’effondrer entre mi-2010 et mi-2011. La communication inter-cluster ne fonctionne pas alors qu'elle était prévue au design de l'architecture.

Je viens de lire la première partie du Dossier sur Bulldo ! Est franchement je suis imprésionné ! Très beau boulot de la part de Canard PC pour les explication ! Ensuite ils on l'air plutôt optimiste ! Et il précise bien que si les appli' seront compilé pour Bulldo alors les performances seront au Rendez vous !  
 
Je garde la suite pour se soir !

Belle question. Ça pourrait donner des perfs S-T intéressantes si c'est le cas.

Et si AMD vend ça comme 4 coeurs, tout bénef vraiment.

Après, je calcule 360- mm² sur un FX-12 en 28 nm. Donc vraiment, pourquoi pas...

Tu as brisé tous nos espoirs

Une chance de le voir apparaître pour Piledriver ou bien... fonctionnalité gâchée bien que partie intégrante de l'archi ? Vraiment dommage

 
Si Intel est planté de L'HT avec ça je ne vois pas pourquoi AMD et son Bulldozer serait exempté    
 
Ils ont, normalement, de quoi faire du Linpack dédié a leurs produits.
 
Pas screen temp cores Bulldo ?    

 
Bulldozer n'est pas un mauvais processeur, il va simplement souffrir effroyablement du fiasco d'AMD sur la communication qui l'entoure. En laissant le marketing mentir en parlant d'une "nouvelle architecture octo-core", tout le monde s'attend évidemment à 2x les performances d'un i7 2600K. Au moins. Bulldozer apporte un gain significatif par rapport à K10.5, mais le retard était tellement grand avec Intel qu'il ne peut se battre que sur les prix ... ce qu'AMD fait avec succés sur les GPU. Donc tout est une question de communication, mais clairement, les FX ne répondent pas aux attentes créée par AMD.

 
Ça dépend pour quelles raisons AMD n'a pas pu l'activer à temps, mais si ils y arrivent dans un nouveau stepping, ce serait un joli coup. Le hardware de l'HT était présent dés le P4 Willamette de 2000. Pourtant, il n'a été activé que bien plus tard, quand Intel a réussi a le faire fonctionner (à peu prés) correctement. Il est fort possible qu'AMD y parvienne aussi dans un "Enhanced Bulldozer"... Je n'ai rien dit

J'ai fait mon curieux http://www.hardware.fr/marc/
 
C'est assez explicite  

 
Pas au final assez de perfs pour justifier cela ? Bug dans l'implémentation dur à résoudre ? Bref, plein de questions qu'on peut se poser
 
Nouveau stepping je pense pas, on aurait des trop grandes disparités de perf et voilà quoi
 
Nouvelle gamme au pire. Donc Enhanced.
 

 
Excellent !  

1) Parce que bulldo date pas de 2005. Quand on y regarde bien, AMD s'adapte toujours à l'architecture Intel du moment. La réponse au core2 duo (gros cache) c'était le K10 (cache L3). Bulldo reprend les specs du nehalem de 2008 (pseudo SMT, quantités de cache équivalentes). Nehalem est aussi une architecture haute fréquence, sandy bridge encore plus (par exemple, les latences du L2 augmentent).
 
2) Parce qu'il y en a beaucoup. C'est bon pour les serveurs. Bulldo est une archi serveur. 16 vrais core.
 
3) tout pareil... les serveurs
 
4) Parce que le single thread ça sert à rien d'autre que les benchmark. Si un logiciel demande vraiment de la puissance de calcul, il est parallélisé. Tout est parallélisable.

16 vrais cores ?  

Donc c'est bel et bien un octo (moisi, ça va sans dire)  
 
Ca explique le passage de 3 à 2 pipelines par "core", l'objectif était bel et bien de maximiser les perfs à nombre de threads réduit.

 
Une unité d'exec n'est pas un core.  

 
Sauf que les benchmarks ont été les premiers à utiliser du calcul parallèle massivement (Linpack, Spec, et jusqu'à Cinebench) alors que la plupart des jeux vidéos sont encore largement peu threadés. Donc c'est l'inverse en fait.

Si un thread est systématiquement exécuté par le même groupe d'unités d'exécution qui se trouve en 2 exemplaires au sein du module, ce groupe ne peut être appelé que "core"  
 
On peut au passage déduire des perfs MT que les perfs de chaque "core" sont médiocres, donc vendre ça comme un "super quad" n'aurait pas été possible (attente supérieure et non inférieure à un octo "banal", tout du moins en utilisation courante).

Non mais faut arrêter, les jeux vidéo sont multithreadé depuis un moment
 
La preuve, la génération de console HD (de 2005 donc) ont des proco multicoeurs et forcément les jeux sont optimisé pour (et que vu qu'aujourd'hui c'est souvent des portages consoles > pc ).

 
Et la charge cpu, elle est identique aussi dans les jeux ?  

Faudrait voir à pas confondre "optimisé pour" et "bricolés pour tourner sur"
 
Les jeux vraiment multi-thread existent (bien que le gain ne soit que rarement concret), mais curieusement les jeux désoptimisés à mort sont carrément plus nombreux.

 
Le début de la conception si.
 
2/ C'est pas 16 coeurs Ni les perfs qui vont de paire avec. Explique moi en quoi c'est mieux d'avoir 16 "coeurs" (entre guillemets) INT pas top que 8 bons INT ?
 
4/ Pas d'accord. Les jeux, et certaines applis restent pas tellement parralélisées...