Reprise du message précédent :
  ES de sortie
!

peut-être que wizerty va recevoir qques ES s'il arrive à faire des exploits en o/c avec les AMD actuels

 
en même temps là on parle d un cpu 16 core... gravé en 32nm quand bien même... 16core quoi
 
doit y avoir de latence dans les caches tout ça
 
d'avis qu'une version 6 ou 8 core de bulldozer devrais mieux roxer
niveau enveloppe devrait y avoir moins de latence, moins de fuite, tout ça quoi

Ouais mais le 16 cores offre le Quad-Channels.

bon alors, ça fonctionnera sur chipset AMD 7xx et/ou 8xx ce bordel, ou pas ?

Physiquement parlant, il y a aucun soucis... après .... on n'en sait rien pour l'instant...
 
pour les 8xx, il y a une très forte proba... mais en info, difficile de prédire...

Sur le "buldoblog" c'est indiqué;
 

 
On peut supposer qu'ils feront de même pour les modèles desktop.
Vu que les modèles grand public ne seront que dual channel il ne devrait pas y avoir de soucis, faudra surtout voir au niveau support bios des fabricants de mobos.
Maintenant si par la suite, ils proposent des modèles 12-16 cores avec le tri-quad channels(?), là ça ne fait aucun doute qu'il faudra changer de mobo/chipset.
 
Mais bon on n'est pas encore là.. ^^  

Depuis le temps qu'on l'attend ce Bulldozer ... Il a intérêt à poutrer sa mémé !
 

Y'a quand même un truc qui reste surprenant:
- sur bulldozer AMD décide d'augmenter le nombre d'ALU.
- sur ontario il le diminue.
 
Bon alors c'est quoi qui optimise le rapport puissance/conso ?
Visiblement AMD a du mal à se décider........
 
Si encore ontario était un proc ultra simplifié avec un pipeline hyper court, pas de out of order, une FPU partagée, on pourrait comprendre. Mais là je ne vois pas la logique....

 
C'est un peu plus compliqué que ça. D'abord, il faut considérer un point très important : Ontario vise le meilleur rapport performances/consommation possible avec le paramètre "performances" fixé à 90 % d'un CPU grand-public ; Bulldozer vise le meilleur rapport performances/consommation possible avec le paramètre "performances" fixé à un point inconnu, mais sans doute quelque chose comme 110 % d'un CPU grand-public, par core.
 
Donc déjà, de base, Bulldozer doit être plus gros. C'est pareil dans plein d'autres domaines, par exemple en aéronautique/spatiale. Les constructeurs cherchent toujours le moteur le plus efficace, mais sur un Cessna tu auras un moteur à hélice, et sur une fusée genre Ariane, t'auras un moteur à hydrogène liquide : à problèmes différents, solutions différentes.
 
Ensuite, il faut garder à l'esprit que tout est relatif, l'ajout d'une ALU dans un core de Bulldozer a un impact relatif sur la consommation moins important que sur Bobcat, parce que sur un die de Bulldozer, tu as aussi de grosses FPU (et ça, ça consomme beaucoup) plus tout un tas de composants qui ne sont pas sur Bobcat, ou en plus petit nombre.
 
Et il y a peut-être d'autres facteurs, par exemple, Bulldozer est peut-être destiné à des workloads dont l'IPC intrinsèque est en moyenne plus élevé que les workloads typiques que Bobcat devra exécuter.

Oui j'avais bien compris la différence d'orientation entre ontario et bulldozer.
 
Mais ce que je voulais dire, c'est qu'il se trouve que l'architecture ontario semble rester assez lourde:
Un out of order c'est lourd, ce n'est utile que si le pipeline reste relativement long, la FPU supporte les SSE3 donc doit faire 128bits tout comme la FPU d'un coeur bulldozer,....
 
Dans ses conditions ça ne mange pas de pain de laisser la troisième ALU.
A moins qu'AMD considère qu'elle est vraiment très peu utile...Mais en en rajoute une quatrième sur bulldozer!
 
En fait ça me rappelle l'époque où INTEL croyait dure comme fer au netburst (très long pipe), mais en même temps développait le pentium M (pipe court) pour portables.
Y'en avait forcément un des deux qui n'était pas tout à fait dans le vrai, on sait lequel  

AMD ne veut tout simplement pas faire une merde tortue comme l'Atom.
Il vise 60% de perfs en plus, au minimum, afin que l'utilisateur soit confortable.
Et le proco ne consommera pas 60% de plus...
 
Ontario -> Netbook
Llano -> Portable et Desktop BDG (2 cores) et MDG (4 cores).
Zambezi -> Desktop MDG (6 cores) HDG (8 cores).

Je ne vois pas trop le rapport avec l'Atom.
 
Pour rappel l'Atom est un rebut de plusieurs années  (et beaucoup d'argent investi) dans le programme de GPU computing x86 (mauvais concept à la base) basé sur netburst (encore pire).
Bref bon à jeter entièrement à la poubelle, sauf qu'en général ça fait moyennement rire le milieu boursier.
Donc on a refourgué ça aux acquéreurs de netbook, ça leur suffira bien.
 
ATOM c'est du in order sur un pipeline long, ce qu'il ne faut pas faire.  
Les penryn CULV (45nm Hk également), qui ne sont pourtant pas issus d'une architecture spécifique aux basses conso, sont déjà bien meilleurs à conso similaire.
 
Quite à baisser l'IPC, ça n'aurait pas été plus homogène de faire un quad avec des coeurs simplifiés (pas d'ooo, court pipe, faible IPC) ?

 
La gestion de l'OoO a forcément un coût, mais ça dépend de l'implémentation, et ce n'est pas forcément très lourd. La preuve : l'ARM Cortex A9 et le VIA Nano sont des processeurs OoO, pourtant ils sont tous deux orientés low-power (surtout le Cortex). Et l'OoO permet surtout de tirer parti de la largeur du pipeline (i.e. du nombre d'ALUs/AGUs) plus que de sa longueur.
 
Et la FPU de Bobcat fait 64 bits, elle traitera donc les instructions 128 bits en deux passes, comme l'Athlon 64 en son temps…

Ah ok je savais pas pour la FPU 64bits.
Moi je croyais que l'ooo c'était surtout pour éliminer les dépendances...
Enfin du coup ça va encore plus dans mon sens    
 
Nan mais en fait t'as surement raison.
Doit y avoir  des ooo avec des algorithmes moins pointus, et basés sur une file plus restreinte.
 
Ah un dernier point pendant que je vous tiens:
La L2 partagée, c'est juste pour limiter le nombre d'accès simultanés à la L3, c'est ça?
On sacrifie la latence L2 pour améliorer la latence L3 ?
Et la L3 c'est pour faire profiter les applis à faible threading de toute la cache dispo?

 
Ben l'OoO permet d'exécuter les instructions dans le désordre quand il n'y a pas de dépendances, et sans ça, il est difficile d'exploiter efficacement 2 ALU, sauf à recourir au SMT comme Intel l'a fait sur l'Atom. D'ailleurs, même avec l'OoO, il me semble que l'IPC moyen des applications courantes tourne autour de 1 sur K10, Nehalem, etc.
 
Et forcément, si ton implémentation OoO doit permettre de gérer efficacement 4 ALU et 3 AGU (ce qui semblerait être le cas de Bulldozer) il va falloir quelque chose de nettement plus costaud que pour 2 ALU, un Store pipe et un Load pipe, i.e. le cas de Bobcat ; d'où le faible coût de l'OoO sur Bobcat.
 

 
Je ne suis pas sûr d'avoir compris ta question. Tu demandes pourquoi le L2 est partagé au sein d'un modue Bulldozer, plutôt que par core ? Ou pourquoi il y a un L2 tout court ?

 
 
osef ils ont pas l USB3 natif

Dans l'ATOM il me semblait que c'était surtout pour palier les faiblesses du pipeline long...
 
Dixit Dr teraboul:
"’une architecture In Order se contente souvent de 5 à 8 étages pour minimiser la perte de temps lorsqu’une pénalité survient"  
"Pour l’HT, l’utilité coule de source : vu l’architecture interne de ce core, il est très important d’utiliser au mieux le pipeline qui, non seulement est In Order, mais en plus est profond de 16 étages"
 
 

Oui c'est ça  

 
Oui l'HT permet de "boucher les trous", tant en largeur qu'en longueur. En l'occurrence Sam souligne l'intérêt de l'HT pour éviter de perdre des cycles, ce en quoi il a tout à fait raison, mais ça on peut le faire avec du FMT (fine-grained multi-threading, comme sur Niagara par exemple). Le SMT d'Atom permet également d'exécuter des instructions provenant de 2 threads différents au cours d'un même cycle, donc de profiter en plus de la largeur de l'architecture.
 

 
Le fait de partager le L2 entre deux cores, donc au sein d'un même module permet une communication rapide entre les deux cores, mais aussi l'optimisation de l'utilisation du cache : pas besoin de recopier les mêmes données dans 2 caches distincts, comme ça arrive souvent quand les caches ne sont pas partagés.
 
Et puis il ne faut pas oublier qu'au sein d'un module, pas mal de choses sont partagées, en particulier le scheduler. Donc il est assez logique que le cache L2 le soit également. Pour communiquer avec un autre core, faudra passer par le L3. Ça signifie également que la communication entre deux cores au sein d'un même module sera nettement plus rapide qu'entre deux cores faisant partie de modules différents.
 
Du coup je me demande quels mécanismes de scheduling de threads il peut y avoir, parce que dans l'idéal il faudrait que les paires de threads susceptibles de partager beaucoup de données soient exécutées sur un même module, mais d'après AMD, l'OS ne voit que des cores, donc je ne sais pas trop comment ça sera géré, ni même si ça sera géré tout court.
 
D'un autre côté, si tu n'as que 2 threads à exécuter, tu as peut-être intérêt à les balancer chacun sur un module distinct, pour profiter de toutes les ressources disponibles (notamment FPU, et puis il y a peut-être quelques bottlenecks ici et là quand tu as un module qui exécute 2 threads). Mais ça consomme probablement plus, d'autant que le power gating doit être par module et non par core, donc si tu as 2 threads chacun sur un module, ça fait 2 cores en idle et du leakage pour rien.
 
Faut voir !

 
Ba justement, les threads sont vraiment gérés de façon indépendante, donc pour moi l'utilité n'est pas là.
Ma réflexion, c'est que l'accès direct de huit L2 à la L3 aurait créé trop de contraintes, et obligé de diminuer fortement la latence de la L3.
D'où un étage intermédiaire...
D'ailleurs la latence du L3 des x6 a déjà été abaissée par rapport aux x4.
 
 

Allons plus loin dans ce raisonnement:
Pour une appli monothread, on gagne bien 0-35% à utiliser un bi-coeur plutôt qu'un mono-coeur, non?
Donc ne pourrait-on pas carrément utiliser deux coeurs par threads?
A moins que les applis multithreads soit déjà trop optimisées pour qu'il n'y ait plus rien à gratter à paralléliser chaque thread...
 
Comment ça se passe sur un quad actuel ?
Est-ce qu'une appli mono-thread est traitée de façon plus rapide que sur un sempron (on utilise deux coeurs)?
Est-ce qu'un appli bi-thread est encore deux fois plus rapide (utilisation de 2*2 coeurs)?
Est-ce qu'une appli quadri-thread est quatre fois plus rapide (pas logique finalement)?
 
Je sais que de toute façon avec le mode turbo, on a désormais intérêt à éteindre des coeurs pour redistribuer leur TDP à d'autres.

 
Tu veux dire augmenter la latence, je suppose. C'est un facteur qui joue en faveur du choix d'un L2 partagé, mais je ne pense pas que ce soit le principal. Mais c'est plus une intuition qu'autre chose, je ne suis pas en mesure de le prouver par A + B. D'après TechReport, la latence du L3 d'Istanbul est la même que pour celui de Shanghai : http://techreport.com/articles.x/17005/4
 

 
Deux cores sur le même thread, ce n'est pas possible, AMD a été claire là-dessus. Ce que je veux dire, c'est que si tu as disons un Zambezi (4 modules, 8 cores) et une application avec seulement 2 threads, tu as deux possibilités :
 
A — Les deux threads sur un seul module (mais un core chacun, bien sûr), disons le module 0, et les modules 1, 2 et 3 éteints ("power-gatés" ).
B — Chaque thread sur un module différent, disons module 0 et module 1 et les deux autres modules éteints. Mais dans ce cas, tu as le core 0 du module 0 qui bosse, et le core 1 du module 0 qui ne fait rien. De même, le core 0 du module 1 bosse, le core 1 du module 1 ne fait rien. Or, je ne pense pas que le power-gating d'un seul core au sein d'un module soit possible.
 
Donc pour résumer, l'option B induit une consommation plus importante, mais éventuellement de meilleures performances. Dans certains cas, l'option A sera plus performante, particulièrement si les deux threads doivent beaucoup communiquer, et que les données tiennent dans un seul L2.
 
Edit après avoir vu ton edit : tu ne peux pas mettre deux cores sur un thread, que ce soit Bulldozer ou autre. La raison pour laquelle tu vois parfois un petit speedup (~10 %, rarement plus) d'une application mono-thread sur un dual-core, c'est qu'il y a toujours plein de petits threads en tâche de fond sur un ordinateur, pour l'OS et autres conneries, et un single-core doit tout gérer tout seul, tandis qu'un dual peut allouer un core à la grosse application pendant que le second s'occupe du reste.
 
Et naturellement, tu peux aussi avoir des différences secondaires, entre le single-core et le dual-core, comme un cache plus gros, un bus mémoire un peu plus rapide, etc.

Pourtant j'avais vu quelquepart une loi mathématique (sans doute empirique) qui simulait la performance en fonction du nombre de coeurs/ nombre de threads. Faudrait que je retrouve ça.
Faudrait aussi que je retrouve les tests des premiers X2 en monothread.

Putain mais t'as raison, globalement en mono-thread c'est pareil !
A l'époque j'avais du me faire induire en erreur par des benchs mixtes. Ou par des benchs bizarres genre ça :
http://static.pcinpact.com/images/bd/news/17018.png
 
Mais alors l'histoire du pentium D handicapé par son bus inter-core, c'était de la fumette ?
 

 
bah oui... c est les rageux du "quad natif" lorsqu'on parlaient "amd K8" qui se montait le kiki
 
 
par contre à une epoque tu voyait des bench de plateforme bi socket... comme si un bi socket (de l époque, sur les génération récente pas mal de goulot d'étranglement entre les socket on été supprimé) donc plusieurs cpu c'était comparable à l'époque à un cpu qui a plusieurs core sous la même enveloppe

 
Si tu penses à la loi d'Amdahl, c'est une loi qui permet de déterminer le speedup maximal d'un programme en fonction de la portion du programme dont tu améliores les performances, et dans quelle mesure.
 
Et c'est généralement appliqué au parallélisme, mais ça suppose que tu augmentes le nombre de threads. Ce n'est pas une loi empirique mais théorique, et elle ne donne que le maximum, en aucun cas une estimation des performances réelles.
 
Par exemple, la loi dit que si tu as un programme avec 50 % de code parallélisable et 50 % de code non parallélisable, alors au mieux, avec une infinité de processeurs, ça sera deux fois plus rapide qu'avec un seul, parce que le temps d'exécution de la portion parallélisable tend vers 0 tandis que le reste demeure constant.
 

 
La communication par le FSB pour le Pentium D était effectivement un handicap, de même que pour les Core 2 Quad, mais en pratique ce n'est pas trop gênant, du moins sur desktop. Sur serveur avec 4 à 8 sockets, le FSB devient franchement problématique, et c'est la raison principale de la popularité des Opteron à l'époque. Depuis Nehalem et le QPI, cet avantage qu'AMD avait a disparu.

c'est toujours le même qui voit son inter-core le ralentir d'ailleurs

Merci Alexko, je m'endormirais moins bête ce soir

De rien, faut bien que ma geekitude (© Ségolène) serve à quelque chose…

Dédicace @Wirmish > http://www.hardware.fr/news/11060/ [...] intel.html !

 
 
ouaip
 
NV va enfin racheter VIA

Ce serait chouette.
Comme ça nVidia aurait et des GPU de merde, et des CPU en bois...!

Troll des montagnes verdoyantes de la forêt aux pins dorés par la lune...  

 
c'est bien beau... mais dans les faits, ça changera pas grand chose...

Ça veut juste dire qu'Intel a bien fait de faire ça puisque ça n'a été que tout bénef pour lui.

 
je pense qu'Intel va jouer encore plus techno que commercial    
 
Au moins avec cette méthode il n'est pas possible de discuter.
 
   

Un bien bel exemple de que voilà
Plus la peine d'essayer de se cacher, c'est plié!

 
troll oui et non
 
la question se pose avec le devenir de windows
 
et surtout le noyau de windows 8 (il est qu'estion d'open source ET aussi d'un noyau unique windows/windows embedded/windows "phone"... donc "windows PC desktop" s'affranchirait du "x86" only reste le besoin du x86 pour la retrocomp des logiciels ... mais pas de l'OS)
tu rajoute les dernière innovation en terme virtualisation qu il y a aura dans le sp1 de windows 7
 
tu rajoute que tegra tourne sur windows 7 embedded
 
si on lit entre les lignes on a envie de dire que Windows 8/9 va s'affranchir d'une partie du pendant x86 des X86-64 en l'émulant (bah oui les cpu multicore ça peut aussi servir à ça)
 
donc j ai envie de dire que d'ici qqs années le x86 (ou x86-64 comme il est percu actuellement) sera déclassé dans un registre à la SSE pour être surtout là en terme retrocomp
en cela des instruction hardware x86 pure ne nécessiteront plus d'être des version "de roxor"
 
et les cpu risque de plus en plus de revenir à une archi style "RISC" (attention je dit bien "style" je parle pas d'archi RISC comme on a connu du temps des power pc)
 
du coup pour NV ça serait pas inintéressant d avoir l existant VIA (pour la licence x86.... histoire d'ajouter un registre "d'instruction x86" à un futur "super tegra" ...registre qui intégrerait les instructions x86 trop lente à émuler sur toute les instructions x86)
à moins que NV puisse pécho une licence particulière chez intel sans passer par VIA (mais j'y crois pas trop)
 
faut pas se leurrer le x86 est génial en terme compatibilité
mais est aussi très contraignant (c'est pas pour rien qu on a pondu x86-64 qui n'est pas qu'un bete passage de 32 à 64bits)
 
et y a que intel pour vouloir faire croire que les dev programme en langage machine pur x86  

Tu aurais plus d'infos  
(je sais, c'est pas le sujet )

 
La vache, j'ai rien compris…  

enfin  
mais dans et avec, quel interêt
via et LE spécialiste mini-ITX, ITX et µATX. Quel interêt supplémentaire NVIDIA aurait de s'investir par le biais de VIA ? sachant que ION-II est une solution en soit !

non mais :
HYPER
MEGA
EXTRA

quoi

bénef ouais qui paye, crétin !!!+1.000.000 et bien malheureusement, dans le vrai    
 
EDIT:
 

MEGA en effet
Go MP, ce sera mieux
avant que Zack38 s'énerve

Si cette tendance aide à mieux comprendre les tenants et aboutissants dans la conception des nouveaux processeurs et les choix d'AMD (et d'Intel), je ne suis pas sur que ce soit du HS

j ai rajouté des chtites petouilles en rouge pour aider un peu à la clarté... au moins sur l intérèt que je verrais à racheter VIA
 
et le fond de ma pensé sur le futur de windows "portable et desktop"  mais aussi applicable pour les serveur vu que de plus en plus le parc serveur passe à la virtualisation...  
 
donc les contraintes hardware s'efface peu à peu... on ne parle plus de composant de X ou Y... mais bien de composant qui amène une fonction
la couche inérante du hardware du fabricant X ou du fabricant Y nécessitant le drivers Z ou W on s'en tape en virtualisation   contrairement au PC de Mr tout le monde qui nécessite le drivers specifique
 
exemple sur le PC de Mr tout le monde la carte son si t as pas le drivers du fabricant ça va plus ou moins être "audio HD windows"
on peu arriver à la Même chose avec le cpu
 
j'ai envie de dire que la partie "drivers" risque dans de prochain windows d'être déporté au niveau de l'UEFI
les drivers n'attaque plus le noyau même de l'OS
on en vient alors à se dire... pourquoi pas même l'extraire de l'OS  
donc le drivers arrivé un moment donné s'intégrera dans le firmware ou bios de la mobo, de la CG... (enfin un vrai plug & play)
 
bref ça ne sera plus à l'OS de deviner "t'es quoi la carte qui vient de te présenter à moi" (et donc besoin d'une liste de drivers longue comme le bras pour 'tester' une correspondance existante)
 
c'est bien le hardware qui SE PRESENTERA et indiquera comment on peut l'utiliser
 
bref démarche inverse
 
si il manque qqchose dans le PC pour une tache... hop emulation
 
je tiend juste à rappeler que MS le fait déjà avec WARP (savé le truc qui fait passé votre cpu pour une carte dx11 si vous en avez pas une)