Reprise du message précédent :
C'est x86 qui a parler du treading hardware
ALU chez wiki
 
Pour la route: (roadmap amd evidement)
http://img58.imageshack.us/img58/3665/280476sw.jpg  
 
Sa vient de PCI donc    

 
 
Tu connais pas GOOGLE ou WIKIPEDIA? Bon je vais t"eclairer quand meme. Tu dois te souvenir du Hyperthreading des pentium 4? En gros ca permet de faire croire a windows que tu as un second processeur , tu peux traiter deux thread a la fois(thread on va dire grosso modo programme en mémoire meme si c'est plus compliquer que ca). Le seul problem c'est que tout ceci est virtuel disons c'est pas un vrai second processeur en hardware. L'hyperthreading est une instruction en plus qui est gerer par windows. La amd parle d'un threading hardware c'est a dire gerer par le processeur.

ce qui veux rien dire de clair

 
Ca me rappel le courte d'architecture parallel a la fac. C'etait bien violent et super chaud a gerer. Nous on fesait de l'architecture parallel(en prog) sur deux machines relié en reseau.  Mais le principe est le meme.

En gros, ça veut dire que physiquement, tu as plusieurs processeurs, mais que le soft n'en voit qu'un, et c'est le Hard qui s'occupe de diviser le boulot.

 
Mdr hey il faut qu'il fasse un effort aussi.

Rien ne vaut linux pour bien comprendre le fonctionnement d'un thread, des priorités, des semaphores etc. Ca me rappel les cours théorique de noyau.

Ok
Dans l'immédiat les fondeurs prennent le chemin inverse on dirait , les cores sont bien visibles et c'est l' OS qui gère    

bin ouais, mais bien qu'étant développeur plustôt proche du matériel (donc pas du php ), on me sortirai "threading hardware" sans me faire la description claire du principe, ça me semblerait aussi explicite que "poutrelle volante" comme association de mots, donc je vois pas comment un neophyte pourrait saisir les tenants et les aboutissants de la chose.

 
Oui mais imagine un processeur bicore avec du threading materiel. L'os va voir deux cpu mais en puissance tu auras 4 voire plus. Enfin en theorie. Et en plus gerer de maniere matériel.

 
Ba direction google lol ou wikipedia. Comme pour tout l'informatique sur le net ,il y a tout ce qui faut , du master en architecture au neophyte ,il y a des documents pour tout le monde. Ceci dit c'est vrai ce sont des notions pas simple a comprendre quand on a pas eu le nez dedans depuis longtemps.

ouais bah c'est pas ça si tu parles du threading hardware dont parlais Sam dans sa news sur x86.
 
comme quoi hein

Ou alors full threading hardware , 4CPU inside et Win98 n'en voit qu' un

 
Moi je parle de l'hypertreading d'intel et j'ai evoquer brievement le treading hardware(qui est l'inverse du ht d'intel.Un CPU Dual Core ne serait ainsi vue par windows(ou linux qu'importe) comme un seul processeur disposant d'une puissance théorique quatre fois supérieure à celle de quatre CPUs.

Ca apporterait plus de perfs si c'était géré en hardware ?

 
 
Je vais faire plus simple en un processeur dual core avec le threading matériel  serait vu comme un simple dual core sous windows mais qui carburera grave plus. Avec l'ht pour un cpu monocore ba on voit deux un cpu un physique et l'autre logique. Meme si c'est pas un vrai cpu.

 
En théorie ca sera quatre fois plus puissant a ce qui est dit. Dans la pratique faut voir ,si déja ca apporte deja 50-75% de perf en plus c'est deja ca.

 
C'est transformer plusieurs coeur physique en un logique. Au lieu de voir quatre coeurs (donc 4 cpu) sous windows ba on en verra un seul equivalent a un 10gz par exemple. Avantage pas besoin d'application spécialement optimisé pour cette architecture vu que le system d'exploitation verra pas plusieurs cpu mais un seul. Alors que l'hyperthreading la, il  faut que ca soit optimisé pour sinon ca sert pas a grand chose.

bon il faut (essayer) d'expliquer ce que sont les choses.
 
vu du développeur (et utilisateur en cascade):
 
1) un cpu ne fonctionne que de manière séquentielle (un flot d'instruction unique).
 
2) des fois on "aimerait" bien pourvoir suivre des flots d'éxécutions mutiples en parallèle: plusieurs programme en parallèle.
 
=> pour cela on a inventé le multitâche préemptif, où on alloue des portions de temps a des bouts de programmes (process/threads). l'illusion est souvent correcte.
 
ce que l'on appelle un thread est une entitié, réprésentant disons ou encapsulant, un flot d'instruction. initialement c'est une primitive logicielle (qui n'a pas de représentation matérielle)
 
3) des fois on veut une meilleure qualité de parallélisme de programmes => alors on employes plusieurs CPU.
 
maintenant revenons a notre contrainte de montée en performances, et où ces concepts d'hyperthreading, de vrai multi-cpu ou de threading-hardware se placent:
 
- l'hyperthreading:
sur certains cpu, le P4 pour ne pas le nommer, dû au fait que le logiciel existant est optimisé pour un autre architecture de CPU (à tord ou à raison) ou que le flot d'instruction est non favorable, on a inventé le concept d'hyperthreading: simuler la présence physique de CPU multiples pour obtenir un flot mieux alimenté à l'intérieur dudit CPU.
 
conséquences:
1) le cpu a une meilleure efficacité interne
2) potentiellement si l'on cherche un meilleur parallélisme, ça peut aider
3) pour le développeur qui a une séquence de traitement unique pour de bonnes raisons, avoir à éclater son code en plusieurs threads pour aider le matériel n'est pas forcément un progrès => être imposé de threader, comme tout chose qu'on impose, ça peut être une contrainte, que l'on ne peux pas toujours satisfaire.
 
- les multis cores:
 
1) bah c'est cool tu démultiples potentiellement les performances
2) ça améliore le parallélisme des traitements
3) si on n'arrive plus a progresser en mon-core, c'est une solution pour continuer la progression des performances
4) comme pour l'hyper-threading, si c'est pour augmenter les performances, c'est peut être une contrainte que l'on ne peux pas toujours satisfaire.
 
- le "threading hardware" dont parlais la news sur x86:
 
bah c'est la réciproque des deux autres.
 
l'hyperthreading, c'est (par exemple) 2 thread pour un 1 CPU, donc relation:
N threads => 1 cpu
 
le multi-cpu, c'est symple:
N threads => N cpus  
 
le threading-hardware, c'est plus sioux a comprendre l'intêret:
1 thread => N CPUs
 
l'interêt c'est quoi: dans l'absolu, essayer de construire un "boite magique" dans le CPU (disons avec les N CPUs), qui permette d'automatiquement éclater un flot d'éxecution unique vers plusieurs CPU.
 
ce qui permet de lever une contrainte sur les développeurs, à mon goût à raison pour les algos non ou très difficilement éclatables (mais je vois pas trop comment), à tord pour les éclatements explicites (via la primitve os de thread), ceci dit c'est pas un problème on peut toujours threader normalement pour expliciter du parallélisme.
 
mais bon, dans l'immédiat une telle solution technique me parait hautement infaisable (mais bon j'y connais que dalle comparé a un mec qui bosse sur des cpus tout la journée ). où alors la notion de "CPU" dans la relation 1 thread => n CPUs n'est pas la même que la notion actuelle.
 
(accessoirement, un moteur OOO fait déjà une décomposition d'un flot d'éxécution vers de multiples unitées de traitement pour augmenter les perfs par parallélisme, mais bon c'est pas cencé être la même chose)

 
je penses que tu voulais dire "simple core" donc classique je suppose ?

 
rien à voir, ce serait pour lever des contraintes de parallélisme explicite via les threads coté logiciel.

Merci pour ces précisions  

Evidemment, sans "out of order", un proc ne peut traiter qu'une instruction à la fois.
Mais même avec ce dispositif, on ne peut pas paralléliser autant qu'on veut. Même si le proc peut trouver 2 ou 3 instructions à exécuter simultanément, il aura du mal à en trouver beaucoup plus. Donc, il n'est pas forcément très utile de multiplier le nombre d'unités, on risque surtout d'avoir des unités qui n'ont rien à faire

pas forcément, le Pentium était juste superscalaire, pas OOO, et pouvait éxécuter une paire d'instruction en parallèle (avec des restrictions de dépendances bien entendu).
 
c'est juste que le P1 faisait du paire par paire potentiel, le PPRO et les CPU OOO, ont une fenêtre et ont plus de possibilitées pour extraire du parallélisme au niveau instruction. (et exécutent des instructions suivant la quantitée et la spécificité des "ports" )

Le jour où Sam fera des articles ou citations intéressantes n'est pas près d'arriver.

Oui. On ne peut pas multiplier à loisir les unités d'exec. Sinon il y a longtemps que cela serait fait. Les limites de l'ILP (Instruction Level Paralelism) semblent être atteinte depuis pas mal de temps. Il n'y a qu'à voir les résultas très honorables d'un p-M, basé sur le P6. Pendant pas mal de temps on a donc compensé avec la fréquence. Aujourd'hui la fréquence n'est plus possible, et les recherches s'orientent vers l'amélioration du TLP (Thread Level Paralelism).
Il existe un bon article de 2004 sur le sujet :
http://www.aceshardware.com/read.jsp?id=65000333

 
il a l'air super interressant cet article, mais 3km.. je le lirais + tard.
le processeur de Sun à l'air pas mal dans l'introduction là
 
au niveau du ce que amd appelle le "threading hardware" moi la première fois que je l'ai lu je me suis dit que c'était la providence et enfin la réponse d'AMD à intel core.
 
parce que de un, moi en tant que développeur, je déteste les API de threading, non portable, non unifiée entre les langages, et les merdes qu'on rencontre avec tout ce qui gravite autours, deadlocks, partage de ressources, beeeeuh...
donc une telle idée waw ca me réchauffe le coeur
 
et justement quand à la manière de faire, bjone avait l'air de dire que l'OOO était à part mais ca n'est pas le seul moyen de faire ca justement ? comment parralléliser ce qui n'est pas prévu pour être parrallèle au départ, ben en executant tout ce qui est isolé (indépendant de l'odre d'execution), c'est pas pile poil d'OOO justement ?

Yonah Vs Merom : benchmarks
 
http://www.matbe.com/actualites/13 [...] enchmarks/

http://www.matbe.com/actualites/13 [...] et-conroe/
Une cm agp bon marché pour Conroe.

L'article est sans intérêt. On a le droit a des graphiques dont l'origine n'est pas 0 (avec une accentuation gigantesque sur des perfs sur FEAR par ex pour 3 fps sur 80, c'est à dire rien du tout).
Pas mal de benchs synthétiques sans intérêt comme 3dtruc, superpi, Sandra etc...
Et surtout aucune comparaison avec le Yonah puisque seuls des T4000 et T7000 sont testés avec de vraies applications (seulement des jeux qui plus est) . La comparaison sous super PI ne présente aucun intérêt.

Je pense qu'amd a encore une carte a joué avec son architecture K8. En passant a une finesse de gravure a 0.65, améliorant sa gestion de la mémoire cache,augmentant le cache par la meme occasion ,unifiant les cores, unifiant la mémoire cache, corrigeant la gestion des instructions sse et pour finir incorporant le threading hardware. Tout ceci pourrait les mettres au niveau du conroe. Voir mieux mais ca faut voir en pratique .

Oui mais le 65nm c'est pas pour demain chez amd

 
ben c 'est plus un k8  

Lol mais si ,si on rajoute pas le threading matériel. lol Et puis c'est qu'une evolution du core. Une refonte complete amenerait a revoir de A a Z l'architecture.

 
Hélas mais chez ibm ils peuvent produire pour amd si ils arrivent pas a sortir du 0.65. Enfin je sais pas si ibm  a un process en 0.65. Ca doit pouvoir se faire je pense .

article intéressant sur le core duo :
 
http://www.anandtech.com/mb/showdoc.aspx?i=2750

roadmap AMD
http://www.matbe.com/actualites/13 [...] -quadcore/
va falloir attendre un peu avant d'avoir la Rev. G et le 65 nm... du moins sur desktop... 2eme trimestre 2007 j'ai m'impression..., 1er semestre c'est sur...
le 1er 4 core desktop arrive en 2008...

Et les jeux multithreadés ils arrivent quand ?

quand ils arriveront

C'est bien gentil de penser aux encodeurs de vidéos et aux sétiseurs , mais les gamers ça leur apporte pas grand chose pour l'instant le multicore , intel fait un pas en avant pour les progs monothreadés avec le gros cache unifié du Conroe  

 
je vais faire une réponse à la cat prog: boost::threads
ceci dit j'ai pas encore eu l'honneur de jouer avec
 
---
 
le problème pour extraire le parallélisme, c'est le fenêtre de vision sur le code, je veux dire pour pouvoir alimenter deux cores a partir d'un thread/process unique, il faut réussir a extraire des longues portions indépendantes, et ça me parait assez mortel (dans le sens négatif du terme) au premier abord.

en fait tu peux quand même threader correctement un jeu video, c'est jouable, notamment les bibliothèques de calcul physique sont déjà threadées (PhysX/Havok...).
 
Donc sur un jeu récent dans son implémentation, il y a moyen de profiter de cores multiples, mais je doutes que ce soit extensible a l'infini (au dessus de 2/3 cores max pour un jeu actuel).
 
Par contre un serveur de jeu style MMORPG, peut méchamment tirer parti d'une masse de core importante. (tu peux plus facilement extraire des critères de répartition de charge).
 
En fait au sein d'un même algo, plus tu as d'éléments non dépendants entre eux (par localité spaciale/groupe) plus tu peux distribuer ces éléments (les perso d'une ville par exemple), après y'a des algos où tu peux répartir des étapes (le cpu 1 fait l'étape n, le cpu 2 fait l'étape n+1 si y'a pas d'interdépendances, cf le mode AFR des gpu).
 
bon fo voir.