Reprise du message précédent :

 
l'HT n'est interressant que si les pipes sont mal alimentés. accessoirement un pipeline long ayant certainement plus de problèmes d'alimentation et a donc plus de bulles qu'un court (mais c'est plus compliqué que cela)....
 
si c'est pour avoir l'HT sur un cpu qui n'a que peu de bulles dans ses pipes, les threads virtuels ne progresseront que de peu pendant le timeslice de l'OS.
le tout en consommant du transistor, et en privant potentiellement des ressources CPU pour une situation a thread unique.
 
l'HT n'est pas là pour améliorer le multi-tâche, il est là pour réduire l'innocupation des pipelines. ne pas confondre la cause et la conséquence.  
deux threads virtuels pour réduires les bulles, les deux threads faisant qu'on a un pseudo meilleur multi-tâche.

maintenant si tu veux pourvoir entrelacer deux threads au niveau instructions, pourquoi pas.... mais je vois pas trop l'intêret.... ( a part pouvoir prétendre pouvoir faire cela)

 
Cf le post de bjone
 

 
Je n'ai pas dis le contraire, si ? J'ai dis que le cache n'était pas partagé dans les deux cas, ce qui est vrai, ensuite en ce qui concerne les différences d'implémentation des caches entre PD et A64X2 c'est une autre histoire, cf. les articles dédiés à ces CPUs.

Une version serveur du Yonah est prévue.

L'HT c'est du SMT, cad la possibilité de partager le pipeline d'exécution entre deux threads (ou plus selon le niveau de SMT, mais pour l'HT c'est deux), qu'ils soient du même processus, ou de deux processus différents. On améliore donc le remplissage du pipeline, quelle que soit sa profondeur, et qualifier le Yonah de cpu à pipeline court n'est pas très opportun. C'est plutôt le p4 qui fait figure d'extra terrestre, il ne faut pas prendre le problème à l'envers.
 
Le SMT est utile lorsqu'on a beaucoup de threads en parrallèle, donc sur des softs multithreadés : calculs intensifs parallèlisable, bases de données etc...
Certes, cela profite plus  lorsqu'on a des piplines longs et/ou beaucoup d'unités d'exécution (comme le PPC 970, ou les 6xxx "Core" Intel). Rappelons qu'IBM intègre le SMT sur sa gamme POWER, pourtant dispos en multicore, et que le p-D EE HT améliore ses scores avec l'HT sur les softs qui vont bien :
http://www.hardware.fr/articles/56 [...] n-840.html
 
Si le Yonah n'a pas de SMT c'est aussi car :

• le P6 est trop vieux et difficile à modifier sur ce point
• il a peu d'unités d'exécution (moins qu'un K8, ppc970 ou 6xxx)

Le truc c'est que celui qui n'a pas lu ces articles ne peut pas comprendre et se dit que l'aX2 est une bouse.

Il faut vraiment avoir l'esprit tordu pour lire ça

Une question à propos du partage du cache L2 entre les 2 core:
Si les 2 core veulent lire la même zone mémoire dans un interval très court, est-ce que la zone en question sera chargée 2 fois dans le cache L2 dans 2 zones différentes (1 pour chaque core) ou est-ce que les 2 core vont piocher dans la même zone du cache ?

Je ne pense pas qu'il ait tout mis dans le même panier.
Il parle uniquement de l'unification du cache et non de la comunication des 2. Et l'avantage de cette unification est de pouvoir se partager une "grosse" ressource (grosse car unifiée) de manière équilibrée, optimale (genre 1.5Mo pour l'un et 512Ko pour l'autre, ce que ne permet pas un cache 2*1Mo). C'est en cela que le cache L2 est innovant.

Mareek>
Dans cette phrase "De ce fait, les données contenues dans ce cache unifié sont accessibles à l’un ou l’autre des core", j'ai considéré que c'était un OU exclusif (soir l'un soit l'autre). Me trompe-je ?

A priori une seule fois mais Intel n'as pas donné tous les détails concernant son cache L2 unifié, il doit bien y avoir des limitations en cas d'accès quasi-conccurent ne serait-ce que par exemple une mise en attente du CPU1 en attendant l'arrivée en cache L2 de la zone mémoire demandée par le CPU0 peu avant lui, mais bon tout ce qui est gestion du cache & cohérence AMD & Intel n'en parle pas des masses.

Non les données au sein du cache sont partagées, dsl si c'était flou je vais changer le ou par et au moins il ne pourra pas y avoir de mauvaise interpretation.

le SMT n'a d'intêret que si tu as de la ressource pour en profiter.
 
le problème du P4 était qu'il avait un mauvais taux d'uilisation de ses ressources.
un CPU qui a un taux d'utilisation correct ne profitera pas en performances globales du HT, ok si l'aspect comportement en latence t'est important en cas de threading lourd, mais je pense que c'est se fourvoyer dans la démarche.
 
hors a budget de transistor équivalent, un cpu avec un bon taux d'occupation sera moins "performant" si tu lui impose une virtualisation de contexte comme l'est le HT. il faut peser le pour et le contre.
 
si ton profil d'application c'est du thread, du thread et encore du thread, et bien tu fais un rack de processeur réellement multi-core, pas uniquement virtuellement...
 
enfin c'est comme ça que je le vois, je me fourvoye peut être dans ma réflexion.

merci  

Disons que le combo changement de process + changement d'archi ne rend pas simple une analyse du die de ce côté, je n'ai pas vraiment envie de partir dans des théorie foireuses et Intel n'a pas répondu précisement à mes questions à ce sujet.
 
A priori je pense plus qu'il s'agit d'économie du côté du cache L2, ce qui explique d'ailleurs la taille du die. Maintenant, d'ou viennent ces écos ? Bonne question d'autant que bon un cache L2 c'est un cache L2, il n'y a pas 36 moyen de faire les cellules ... c'est pour ça que je fait mention d'une éventuelle redondance des cellules sur le Dothan mais bon.

C'est aussi mon point de vue, mais peut être que je me trompe également.

En même temps, à part sur XE qui sont hors norme, l'HT n'est jamais activé sur des multi-core alors que ça pourrait encore bien être utile parfois sur Pentium D !
Le yonah est déjà bi-core, c'est déjà bien ! L'HT ici n'aurait servi qu'à embrouiller windows XP AMA.

Les cores du Yonah communiquent ils en direct ? Je ne le pense pas.
Dans le cas du X2, on peut, en poussant le bouchon, dire que tout est partagé dans la mesure ou les cores communiquent en direct via le contrôleur HTT.

 
Merci pour ces précisions    
 
Que veux tu dire par "éventuelle redondance des cellules du cache sur le Dothan" ?    
 

Parcque 2 core peuvent comminquer entre eux directement ? Sans passer par quelconque mémoire (cache ou système) ? Si oui, ils se disent quoi ?

l'état des lignes de cache ?

ça dépends: les core des Athlon parlent géopolitique et physique quantique alors que les core des CPU Intel parlent de la starac et de voici

Le budget en transitor du SMT est relativement réduit me semble t il.

Le SMT améliore le remplissage dans tous les contextes point (si c'est bien géré). Ensuite il faut voir dans quelles proportions cela améliore les perfs.
 
 
 

Le soucis c'est que le p-D chauffe, et que l'HT fait chauffer. De plus Win gère mal la chose en effet.

C'est le principe du x2. Ils se passent des infos situées en cache, des résultats etc sans passer par la RAM.

Etant donné que les deux cores du Yonah peuvent acceder directement à toutes les données contenue dans le cache L2 et que donc la gestion de ce cache est , qu'elles aient été initialement cachées du fait de l'un ou de l'autre des cores, je ne vois pas en quoi il est interressant de savoir si ils peuvent communiquer directement entre eux, tu as peur qu'ils s'ennuient ? Si cette communication se fait par une partie commune en charge du Smart Cache ce n'est pas en direct mais en interne, mais bon ca change quoi ?

Tout le cache est dispo aux 2 cores ? Mais à quoi sert donc l'allocation dynamique ? Ce serait donc juste pour l'écriture ?

Pour la cohérence des caches entre les deux CPU, cad que si tu veux acceder à une zone mémoire mais que celle ci a été cachée puis modifiée dans le cache dans le premier CPU, il faut que le second soit au courant et puisse avoir accès à cette donnée modifiée qui n'est pas encore écrite en mémoire vive.

Perso je pense que c'est utile dans les cas ou les core traitent des process assez asymétriques en terme de volume de données mais bon je me demande si en pratique c'est vraiment le cas d'autant que bon sous Windows de base une appli n'est pas assignée à un CPU mais passe de l'un à l'autre

Ce que je veux dire c'est qu'avec la com. intercore le X2 peut se passer de partage du L2 et du L1. Me trompe-je ?

Peut-être aussi pour éviter certains problèmes découvert avec l'HT accompagné d'un cache unique ! Non ?
Le fait que parfois, deux threads voulant accèder au cache en même temps ne posait pas des problèmes ? Notament avec les serveurs de BDD je crois ! Là, avec un cache par core, ça limite ce genre de problème !

Il n'a jamais dit le contraire ! Il a juste dit que le cache était plus innovant, ce qui est vrai ! Non ?
Ca ne veut en rien dire que l'aproche d'untel est meilleure que l'autre !

Yonah= pas d'HT.

Les "innovations" c'est bien, mais la finalité de la chose c'est mieux. Si avec la com. intercore on a en pratique la même chose, à quoi bon faire tout un foin du partage de cache ?

Oui, mais 2 core ! Donc si le cache avait été unifié, sans une limite par core, on aurait pu avoir ce genre de problème ! Non ?
 
C'était pour répondre à Fouge

Parcque avec l'archi Intel, le partage du cache est important, et donc c'est bien de le préciser !

 
oui il améliore le remplissage, mais par si tu prends comme caricature possible:
si il bouffe 10% de budget de transistor (qui aurait pu être utiliser pour un port/alu supplémentaire) et en créant un point chaud d'instabilité dans le design du cpu (ce qui pourrait brider la montée en fréquence de l'ensemble de cpu) rien que pour gagner 3% de rendement global, peut être que le jeu n'en vaux pas la chandelle.
 
mais pour ça apparement les ingés d'Intel ont rendu leur copie.... (peut-être qu'ils la corrigeront plus tard suivant le retour d'expérience et le changement de budget technologique, c'est le genre de trucs qui doit se décider au cas par cas, les options s'ouvrent ou se ferment suivant plein de critères)

Certes, quand on est le dernier fabriquant au monde (avec VIA me semble t il) à ne pas intégrer les contrôleurs on die (pour des raisons de coûts de fabrication), c'est intéressant d'avoir une communication intercache.
Marc mettait dans son article le p-D et le X2 dans le même panier concernant le L2. C'est vrai stricto sensus, mais le profane peut en tirer des conclusions hâtives sur le X2, qui n'est pour l'heure pas inquiété par ce Yonah à cache/fréquence égale, d'autant qu'on compare du 65nm vs 90nm.  
Le "K9" (aX2 & co) sera peut être plus inquiété par le Core (Conroe/Merom/Woodcrest).

Oui.  
L'HT reviendra avec l'archi Core.

Tant que Marc est dans le coin :
"4 capacités sont annoncées : 250, 320, 400 et 500 Go, ces disques étant respectivement dotés de 3, 3, 2 et 2 plateaux."
 
Il fallait bien entendu lire "2, 2, 3 et 3 plateaux"

l'intéret du partage de cache me semble évident: avec une quantité de cache par core divisée par 2, le yonah a toujours des perfs supérieure au dothan (même dans les applis monothreads) alors que le nombre de transistors n'augmente que de 10% contrairement aux l'athlon x2 et au pentium-D où le nombre de transistors double avec tous les inconvénients que celà entraine.

et d'ailleurs l'argument du budget en transistor et de l'optimisation globale est aussi malheureusement la cause de la non intégration du support 64bits.
 
Et à mes yeux c'est a des années lumières plus grave que le fait qu'il n'est pas le HT !!!
Ca l'élimine potentiellement (cette implémentation de la famille) façe a tous les cpu 64bits dans les datacenter et dans peu de temps, aussi dans les stations de travail.
 
Si on veux rire jaune mets un serveur SQL 64bits avec un A64 ou un P4 EM64T avec un Windows ou un linux 64bits avec un lot de donné moyennement important, et compare les perfs sur le même lot sur un Core Duo avec le serveur SQL & OS 32bits....
 
Si c'est pour parler de traitement lourd de Datacenter, le Core Duo est déjà -out-, c'est pas pour rien qu'il n'est introduit que sur portable....  
 
après même sans ça très rapidement pour les stations de travail, tu peux rencontrer des traitements sur des gros lots de données pouvant faire ressortir un avantage pour le support 64bits.
 
donc pour moi le non-support du HT pour le Core Duo, c'est normal.
le non-support du 64bits, c'est dommage.
 
un nouveau cpu uniquement 32bits mais double coeur maintenant, si tu le places dans certains contextes pro, c'est comme avoir un SLI de Geforce 4 Ti 4600 à l'époque des shaders en virgule flottante.

Ce qui est certain c'est que la com intercore permet de de limiter la perte de performance qui peut être induite par les transmissions de données d'un cache à l'autre car si il cela crée tjs une charge supplémentaire au niveau du cache par rapport à un cache partagé (il y'a une copie d'un cache à l'autre) cette communication est rapide. Bien entendu le fait d'avoir un cache partagé peut aussi induire des pertes de performances.
 
Mais c'est innovant.