Jeudi 23 Octobre 2014
  Recherche :

Accueil   |  News   |  Articles   |  Forum   |  Contact   |  A Propos

Utilisateurs Online : 5
BP % :
15 Derniers Articles


:: Inscription au site ::
Login :

Mot de Passe :


 Mot de Passe oubli ?
 Pas encore de compte ?
 Enregistrez-vous ici !



:: AMD / Intel ::

Actuellement
recommandé / conseillé :





Origine des visites
Origine des lecteurs d'x86


:: X86 Network ::
X86 Network :


:: News ::
AMD tudie l'anti-HT pour son K10
09-04-2006 23:24:12 - Samuel D.

Indice de fiabilit : 5/8 (Crdible)


L'actualité est morne depuis quelques jours. C'est un fait. Désolés de ne pouvoir vous proposer de news intéressantes, nous avons été contraint de noyer notre désarroi dans l'alcool. C'est donc au bar que nous avons rencontré un ingénieur d'AMD qui tentait, lui aussi, de noyer son malheur dans le même breuvage. Celui-ci nous a ainsi décrit ses craintes quant aux performances du Conroe, dont un Juda à finalement envoyé un exemplaire chez AMD.

Conscient que l'architecture K8 ne pourrait rivaliser avec la prochaine vedette d'Intel, tous ses espoirs sont pour le moment basé sur une nouvelle technologie "révolutionnaire" (c'est notre avis, pas le sien) sur laquelle AMD travaille en ce moment pour l'après-K8. Cette technologie est en fait une sorte d'anti-HT : Là ou l'HyperThreading cherchait à émuler deux processeurs virtuels avec un processeur physique, il s'agit pour AMD d'émuler un unique processeur virtuel avec deux (ou plusieurs) processeurs physiques.

Une carte mère comportant deux CPU Dual Core ne seraient ainsi vue par le système d'exploitation que comme un seul processeur, bien sur d'une puissance théorique quatre fois supérieure à celle de quatre CPUs. Plus besoin alors pour les développeurs de passer des heures dans l'optimisation des logiciels, celui-ci sera directement dispatché entre les différents cores. Du threading hardware, du vrai. Hélas, effrayé par les menaces d'AMD sur sa vie en cas de divulgation, notre ingénieur n'a voulu nous en dire plus.

Quoi qu'il en soit, nous avons maintenant la certitude qu'AMD aussi travaille sur le threading hardware pour sa prochaine génération. Aussi, car Intel est également sur les rails et a présenté à de nombreuses reprises sa vision du threading Hardware. Les années à venir vont donc être complexes pour les deux fondeurs.

Chez AMD, la seule solution pour se sortir de la crise que va, à coup sur, provoquer la sortie du Conroe est d'innover, et sérieusement. AMD ne pourra en effet tirer sur l'architecture K8 comme il l'a fait pour l'architecture K7 (FSB400 et autres n'ont strictement rien apportés). Le K10 sera LE Saint-Graal ... ou ne sera pas. Et pour celui-ci, pas de Nexgen ou autres Alpha en secours.

Chez Intel, le moyen terme n'est pas forcement plus rose. Conroe et consorts vont, certes, provoquer l'euphorie à leurs sortie, mais il ne faut toutefois pas oublier que cette architecture est loin d'être nouvelle et ne restera pas viable très longtemps. Après Conroe et Penryn (déclinaison 45 nm), c'est Nehalem qui devra prendre la relève. Une architecture maintes fois repoussée sur laquelle Intel hésite visiblement encore.

Quoi qu'il en soit, le premier constructeur qui finalisera une technologie viable de threading hardware disposera d'un très large avantage face à son concurrent, pour peu que celui-ci existe toujours...




<<< News Suivante
Les Core Solo ULV annoncs
News Prcdente >>>
In our Labs : Asus N4L-VM DH




** Commentaires (16) **
  Kenjiamo 10/04/2006 - 04:36:35
De toute facon AMD a annulé le K9 justement a cause du conroe ce que j'espére c'est que AMD ne tombera pas dans la meme spiral que intel

j'entend par la que la meme architecture pour un nouveau socket pour jsute utilisé de la DDR II qui en tout cas a cour terme sera moin performant ...

Je ne sait pas ou AMD va mais il y va et je doute que nous aurons des perf en plus ...

Mais a voir cette article je suis trés enthousiaste a l'idée d'une telle chose !!!

Surtout que les performance seront bcp plus général !!!

Enfin de vrai innovation car il me semble ( indice de fiabilité 1/8 ) que le pentium M est un dérivé du pentium III et le conroe un dérivé du pentium M , recyclage ???

bref je suis tout exité a l'idée de decouvrir tout ceci ^__^

  eponge 10/04/2006 - 09:02:08
Une coquille je pense :
"il s'agit pour AMD d'émuler un processeur physique avec deux (ou plusieurs) processeurs physiques"

il ne faudrait pas remplacer le premier physique par logique ?

sinon quel sont les avantages de cette solution par rapport au HT d'intel ?


  braoru 10/04/2006 - 10:42:51
Que le partage des taches entre les cpu se fasse après le compilateur.

Et puis le ht de par son fonctionnement ne peut véritablement être considérer comme 2 cpu mais plutôt comme une optimisation de la rentabilité.

Par contre je me demande comment ça se passera aux niveaux du cpu pour ce genre de chose, on se retrouvera avec une séparation pré décodage ou post décodage ? Car une séparation post décodage pourrais être possible non ?. Et puis du coup le fusing qui ne semble pas être un gros bosst de performance pourrait la permettre le transfert de groupe de micro-instruction, vous ne pensez pas ?

  Neo_13 10/04/2006 - 10:56:56
Le threading hardware serait une excellente nouvelle... surtout qu'il ouvre la porte à des cpu plus spécialisés...

Ca me rappelle quelque chose :
http://www.x86-secret.com/articles/cpu/pdpxe/dualcore-7.htm

  braoru 10/04/2006 - 11:04:39
Oui Neo_13 tu à raison, l’on pourrait bel est bien voir la création d’ensemble de processeurs dédier, mais je me demande comment le cpu lui-même pourrait faire la différence, il s’agirais alors de processeur dédier à des jeux d’instruction avec tous ce que cela implique ?

  Minuteman 10/04/2006 - 11:32:47
Au niveau de la gestion hardware des threads il est difficile de dire comment ceci va être géré, mais je ne voudrais pas être l'ingénieur qui s'occupe de l'unité de décodage. A vue de nez je vois des unités de micro-ops fusion semblables à ce qui se fait dans la nouvelle architecture Intel, mais le résultat serait dirigé dynamiquement vers chaque core en fonction de son utilisation, la bande passante nécéssaire entre les cores sera énorme dans ce cas et il n'est pas certain que les liens HT suffisent pour obtenir un résultat efficace.

En tout cas comme le dit Neo, excellente nouvelle.

  squawk 10/04/2006 - 13:20:42

  Supermattt 10/04/2006 - 16:48:03
Mais je comprend pas un truc. Dis moi Sam ! Pourquoi s'obstiner a faire du dual core et faire du Hard threading pour faire croire a un seul core PLUTOT que de multiplier les unités de calculs un peu à la manière des cartes graphiques ?

  Grosvince 10/04/2006 - 19:26:38
Supermatt,

Les cartes graphiques ont essentiellement à traiter le même type de données, alors qu'un CPU à une vocation généraliste. En gros, un GPU est une sorte de gros DSP, ultra spécialisé même si en ce moment la tendance serait à lui faire faire autre chose que des images...

Je pense qu'il faut attendre de voir ce que donne le Cell (qui est équipé d'un core généraliste et de 8 cores spécialisés) pour voir quelle voie sera la bonne.

En tout cas, le futur s'annonce intéressant.

  mrbebert 10/04/2006 - 19:52:07
Je suis très sceptique sur ce principe ?

Il me semblait que le principal problème des processeurs n'était pas leur puissance théorique, mais l'utilisation de cette puissance. Les processeurs sont capables d'exécuter plusieurs instructions simultanément, mais ils ont un problème pour extraire suffisamment de parallélisme du flux d'instructions à exécuter. L'HT était logique, car il permettait au proc d'aller chercher dans un autre thread de nouvelles instructions à traiter.
Donc, si un proc a déja du mal à trouver suffisamment d'instructions à exécuter, je vois vraiment pas l'intérêt d'en mettre plusieurs sur un même flux ?
(ou alors, j'ai rien compris au principe expliqué ici, c'est possible :D )

  Foudge 11/04/2006 - 11:02:18
Supermattt>
Augmenter le nombre d'unitées de calcul ou de cores montre rapidement ses limites. Ya qu'à voir les pb du dualcore : si le soft n'est pas spécifiquement optimisé pour, le gain apporté par le dualcore sera nul.

Comment résoudre ce problème ? Comment faire en sorte qu'un thread gourmand qui demande 99% des ressources puisse utiliser toute la puissance théorique du CPU (on imagine que c'est un dualcore). L'Hyperthreading ? Et bien non puisque celui-ci nécessite plusieurs thread gourmand et dans cet situation un dualcore est bien plus efficace. A oublier donc...
Comment alors ? En faisant croire à l'OS que le dualcore est un unique CPU logiciel et c'est une unité hard qui va essayer de "découper" ce thread, paralléliser les calculs afin d'exploiter un maximum les 2 cores du processeur.
Et si le processeur est bithread ? Et bien chaque thread sera envoyé à un core, comme sur les dualcore actuel.

Bref il y a théoriquement que des avantages. Le truc qui va poser problème c'est de rendre efficace le fait de faire tourner 1 thread sur 2 cores.

  bill-baroud 13/04/2006 - 09:25:32
C'est une coquille je crois : "Une carte mère comportant deux CPU Dual Core ne serait ainsi vue par le système d'exploitation que comme un seul processeur, bien sûr d'une puissance théorique quatre fois supérieure à celle de quatre CPUs", il faudrait plutôt écrire "comme un seul processeur, bien sûr d'une puissance théorique quatre fois supérieure à celle d'un CPU", non ?

  Magic 15/04/2006 - 12:23:58
> Foudge
Oui et non. C'est plus complexe que ca.
Quoi qu'on face et malgré les reticences "business" des editeurs le multi "thread-process" est une evolution qui fera son chemin.
Ce qui manque actuellement ce sont des langages modernes permettant de programmer "facilement" de cette maniere. Au niveau de la programmation cela reste encore de la prehistoire à ce niveau.

Pour les gains de performances, on est evidemment limité et les gains seront logarithmiques en fonction du nombre de cores.
L'avenir appartient plutot à la multiplication des fonctions plutot que des cores dans leur intégralité.

Par contre, la multiplication des applications/ Services/composants fonctionnant sur la meme machine augmtentera le phenomene de gains.

  sed 19/04/2006 - 18:24:58
Bonjour, je viens d'arriver sur ce forum.
Se pourrais-t-il, que la news parles de tout autre chose. Je m'explique.
A la fin du développement commercial du processeur alpha, dont je crois beaucoup d'idées ont étées reprises (dans les grandes lignes) par les récentes architectures d'AMD, il était question d'une extenssion vectorielle à ce processeur. Une telle extension est bien diffèrente d'une simple extension multimédia comme le sont le mmx/sse/3dnow sur x86 (resp. mvi (motion vidéo instruction) sur alpha).
Une extension vectorielle permet de travailler sur des vecteurs de "grande taille", couramment 64/256 voire 1024 éléments simultanément.
Mais le plus beau, c'est que si une implémentation le supporte il est possible d'avoir une implémentation scalable. Tout simplement si le 'core' de base supporte des vecteurs de 64 éléments, il est possible (et fait notamment sur certaines machines IBM) d'étendre le nombre d'éléments traités en simultané en augmentant le nombre de 'core' dédié ( on passe ainsi à 128,192,256 etc) éléments. Le flot d'instructions ne change pas, seulement la capacité à traiter des données supplémentaires...

  sed 19/04/2006 - 18:41:03
Bonjour, je viens d'arriver sur ce forum.
Se pourrais-t-il, que la news parles de tout autre chose. Je m'explique.
A la fin du développement commercial du processeur alpha, dont je crois beaucoup d'idées ont étées reprises (dans les grandes lignes) par les récentes architectures d'AMD, il était question d'une extenssion vectorielle à ce processeur. Une telle extension est bien diffèrente d'une simple extension multimédia comme le sont le mmx/sse/3dnow sur x86 (resp. mvi (motion vidéo instruction) sur alpha).
Une extension vectorielle permet de travailler sur des vecteurs de "grande taille", couramment 64/256 voire 1024 éléments simultanément.
Mais le plus beau, c'est que si une implémentation le supporte il est possible d'avoir une implémentation scalable. Tout simplement si le 'core' de base supporte des vecteurs de 64 éléments, il est possible (et fait notamment sur certaines machines IBM) d'étendre le nombre d'éléments traités en simultané en augmentant le nombre de 'core' dédié ( on passe ainsi à 128,192,256 etc) éléments. Le flot d'instructions ne change pas, seulement la capacité à traiter des données supplémentaires...

  originaz 17/05/2006 - 20:12:39
hello,
je debarque un peu en retard je presume, mais il me semble qu'il y a des oublis qui trainent, en effet, d'apres moi certaines petites "erreurs" (arrondissements etc ...) ont tendance a se multiplier avec la pluralité des cores, sauf dans le cas de machines dispersées ou l'on se separerait de ce coté "tout passe par le cpu" comme vous l'avez soulevé a une ou deux reprises, l'evolution des gpu et autres cartes dediees ( son dsp etc ...) sembleraient nous indiquer une tendance vers cela, le seul avantage d'apres moi d'un systeme multi core tient dans le domaine des serveurs, ou certaines ressources critiques peuvent etre allouées au processeur x ou y idem pour les cores, mais quand a de gros traitements de calculs, la on butte sur un probleme, il est par exemple toujours d'apres moi de paraleliser certains calculs, comme certaines vectorisations, pi ... et autres, il faut donc voir ou cela nous mene ... et si je peux me permettre un avis tout personnel, l'avenir pour moi est au 64 bits natif, mais le marché n'est semble t'il pas encore pret pour cela ( os, applications...)