Si ca devient une réalité, les CPU vont faire un bond en avant au moins aussi fort que l'avènement du GPGPU... la souplesse du CPU en plus !

Là, j'ai un peu de mal à voir le pourquoi: Les CPU et les GPU sont des architectures CISC, donc, dans les deux cas, nécessitant une programmation utilisant les instructions dites "complexes" intégrées à l'intérieur. De là, le GPGU permet une accélération des instructions graphiques, mais aussi l'usage de cette puissance de calculs pour du calcul brut. le CPU et le GPU pourraient profiter de cette technologie, dans des domaines somme toute assez différents. De ce fait, je ne vois pas en quoi le CPU est plus "souple" que le GPU. D'ailleurs, c'est même pour cela que l'on a dédié un GPU aux graphismes: pour délester le CPU de choses qu'il ne sait nativement pas faire sans une surcouche logicielle dédiée.

en fait, j'avais lu que certaine instruction ne pouvait etre executé en raison du manque d'architecture memoire complexe (ce que Fermi a maintenant: L1 - L2 -unifié et en prime, ECC)

maintenant, c'est a vérifier...

@magellan, delphi_jb parlait de la souplesse en terme de programmation je pense. On peut dire à l'heure d'aujourd'hui que les CPU sont plus souples que les CPU (un CPU gère une stack, a une MMU, peut faire des opération I/O, réagit à des interruptions programmables etc).

@delphi_jb: c'était pas le load/store? Moi ce que j'attends de voir c'est le support du C++...

C'est plus tributaire du langage que de l'architecture, non? Si l'environnement de développement ne permet pas de prendre en compte toutes les finesses techniques du processeur ciblé, difficile de blâmer le processeur lui-même.

Après, vu que le GPU est originellement prévu pour effectuer des calculs mathématiques spécialisés, la réflexion n'est pas erronée. Cela n'ôte donc rien à la validité de la réflexion de delphi



Bon alors: Oui, là, dit comme ça, ça prend un sens. Cela exprime ce que je disais concernant l'inverse pour le GPU, c'est à dire les jeux complexes d'instructions, qui deviennent "indispensables" puisque plus pratique à utiliser qu'à recoder. Typiquement, cela rejoint mes propos concernant le GPU qui a des modules complexes de réponses à des jeux d'instructions intégrés. Donc, c'est une "souplesse" parce que la commande est déjà intégrée. A contrario, cette façon de voir n'aurait aucun sens sur un RISC puisque "tout" doit être codé pour que cela soit pris en charge.


Pour le stack, les interruptions programmables, c'est probablement intégré aux GPU. Par contre, je suis entièrement d'accord pour le MMU et les I/O qui sont spécifiques au CPU (vu qu'on lui confie, de base, le boulot de gérer les I/O).

@magellan, les interruptions programmables et la stack, je crois pas. en tout cas ce n'est pas exposé au niveau de la couche ISA. Je t'invite à voir PTX le jeu d'instructions des GPUs NVIDIA.
Pour moi pour gérer une stack de façon performante sur les GPUs, il faudrait déjà un espace d'adressage unifié (local+shared+global). Hors ça les GPUs ne l'ont pas encore. Ensuite, je pense qu'il faudrait aussi des registres spéciaux (à confirmer), comme par exemple en x86 tu as ESP et EBP. En tout cas en cas de stack overflow, il faudrait que le GPU soit en mesure de lancer une interruption hardware (sinon bonjour les corruptions!).
En plus je pense qu'il faudrait avoir des instructions du genre pop et push aussi, à moins qu'on puisse gérer tout ça de façon software?
http://unixwiz.net/techtips/win32-callconv-asm.html

Merci pour ces informations... c'est tout de même pénible ce manque d'unification
Pour ce qui est de la gestion software, pourquoi pas: après tout, le Direct3D permet d'user de la CG autant que du CPU... alors rien n'interdit de penser qu'on puisse faire des choses exotiques à travers le code.

Ca me rappelle aussi une époque "maudite", où les instructions 3DFx (Glide) posaient problème quand les jeux étaient trop exigeants: il existait des wrappers qui, à la volée, convertissait le glide en D3D, et inversement, des D3D mappant les instructions glide, pour que les CG 3DFx ne soient pas lésées en performances pour certains jeux

Super ont va multiplier pas 30 la puissance de nos ordinateur !
Les développeurs pourront coder comme des singe ont ne s'en rendra même pas compte XD !

Sans blague, j'attends de voir ça en vente car des promesses de technologie révolutionnaire a faible coût on en voie tout les jours !

Attention, 100GHz, c'est la frequence de coupure du transistor, ce qui est tres au-dessus de sa frequence de fonctionnement reelle. D'ailleurs dans l'article original, il est dit qu'a largeur equivalente, le silicium classique atteint 40GHz. Donc vivement la miniaturisation du process...

@ tout le monde:

merci pour ce petit débat. c'est bon de parfois se rappeler un peu le foncionnement de nos composants...

en fait, Dans une news précédente (et partout sur le WEB en checkant un peu), on peut voir qu'IBM a poussé cette puce au graphène a 500GHZ sous azote (ou hélium liquide, sais plus) et a environ 350GHZ stable à température ambiante !

perso, ca me donne l'impression qu'il on bien diminué la marge à 100Ghz afin d'etre totalement sur de la stabilité non ? on descend quand meme d'un 350Ghz stable en aircooling...

Ha et au fait, je parlais bien de la souplesse de programmation...

Magellan,
C'est précisément parce-que les unités gpu et cgu ne sont pas unifiés qu'elles sont performantes dans un domaine particulier.
Et ça n'a rien à voir avec le soft/compilo, c'est le hard.

Le transistor dont on parle est un transistor "spécial" RF/HF, qui va probablement moins monter en fréq qu'un transistor "digital". Donc est-ce que le transistor dont tu parles est du 2ème genre ? (Je précise que là, on s'éloigne de mon champ d'expertise )

Affirmer c'est bien, mais vu que nous n'étions pas là pour vérifier !?!

Je ne sais pas. quand tu parle de transistor "digital", tu parle de transistor a commande carré (coupure instantanée) ?