Reprise du message précédent :

C'est le principe du processeur vectoriel ça

Le problème n'est du coup pas là, mais (éventuellement) dans les charges qu'on lui donnait à exécuter.

x64 c'est pas franchement glorieux non plus dans le genre, mais comme c'est pas du VLIW vectoriel ça passe.

L'expression "on ne frappe pas un ennemi à terre" est devenue obsolète : maintenant il faudra dire "on ne refile pas Raja"

 
...Oui, les premiers Itanium sont basés, en grande partie, sur les dernier PA-RISC de HP, les PA8800 et 8900.  
Le 8900 avait 1.5MO de L1 (!) et 64MO de L2 (!!!) avec 80W de TDP @ 1.1GHZ sur une puce dual core.
C'était du lourd même en 2005 face aux opteron 180.
Une HP C8000 est encore une "belle" workstation sous HP-UX.

Les i740 était puissants comme cartes 2D/3D à l'époque (enfin ça a été vite dépassé par le riva tnt), plus que les nvidia et ati. Mais ça ne valait pas une 3DFX.

Combien de temps restera ce monsieur chez Intel ? Va-t-il se faire virer par le CEO pour avoir émis la moindre critique, ou bien va-t-il partir de lui-même car n'ayant pas eu assez de liberté décisionnelle ?
La fuite des gens compétents chez Intel est très inquiétante pour le géant, ce monsieur va-t-il pouvoir y exercer ses compétences ?
A vos paris...

pour continuer le HS sur le IA64, d un pt de vue technologique, il était bcp plus abouti que le x64, mais une fois de +, une des raisons de son échec étaient les performances misérables sur les binaines x86 et Win32.
AMD en proposant avec x64 une "simple" extension au x86 n'avait pas ce pb et donc proposait au day1 des perfs au moins similaires aux CPU x86 only.
D ailleurs en remontant plus loin ds l histoire, Intel avait déjà tenté l aventure 64bits dès le i860 en 1989 qui était un RISC non compatible x86. Cad 10 ans avant meme le lancement de IA64, Intel avait déjà connu le même échec à cause du manque de x86.
Et en CPU 64 bits RISC non x86, le maitre des années 90 était DEC avec son Alpha qui atteignait déjà 200Mhz quand Intel sortait son 1er Pentium 66 Mhz. L'Alpha monta jusqu'à 1.25 Ghz en 2001, et n avait sans doute pas à rougir face aux P3 et Athlon de même fréquence. L archi et le bus Alpha ont d'ailleurs bien inspiré AMD pour ses K7 et K8, puisque Derrick Meyer and James Keller sont passés de DEC à AMD pour développer ces archi!
Alpha fut revendu à Compaq en 2001, au moment où le IA-64 s'annoncait prometteur: Compaq a préféré l IA-64 et a tué l archi Alpha, avant de revendre les brevets à... Intel, qui s'en est probablement inspiré pour améliorer le IA-64!
Alpha fut une perle d'ingénierie mais tué par le management de DEC qui maintenait une politique de vente exclusive sans proposer de CPU abordable pour les particuliers.
EDIT: article + complet sur le sujet: http://alasir.com/articles/alpha_h [...] apse.shtml

Depuis 30 ans, le x86 est aussi bien le moteur de réussite de Intel que son boulet. Les CPU RISC aurait pu/du prendre le dessus ds les années 90.
Et en 2017, l archi ARM (qui prends ses sources ds les années 80!) semble le plus sérieux concurrent, la compatibilité x86 empeche Intel d'avoir des CPU aussi efficaces que les ARM en perf/watt.
Les CPU actuels ont tellement évolué par rapport au x86 que la portion x86 est vraiment très réduite ds le CPU: alors que Microsoft essaie aussi tant bien que mal de se débarrasser du Win32, Intel osera t il un jour supprimer le support hardware x86 de ses CPU pour ne proposer qu une émulation, comme le SoC 835 de Qualcomm?

 
ah oui, excuse moi, si il y a la meme frequence et la meme quantité de caches, c'est que c'est la meme architecture !!
 
qd a la compatibilité x86 pour expliquer l'echec du IA64... la marmotte. Quand tu as le code, la compatibilité tu t'en branles. C'etait pas prevu pour le grand public de toutes facons.

 
principe du proc vectoriel.... poussé a l'extreme.
 
je ne compprends pas ton passage sur le x86/x64, on ne peut pas faire plus eloigné que VLIW vs x86/IA64, ou il y a bcp de choses faite execution time, en particulier avec un tres gros Front end.
 
Pour x86 vs RISC/ARM, le probleme est de moins en moins vrai. Les proc sont des RISC en interne, avec un gros front end pour faire la conversion. Or le front end a un nombre de transistor a peut pres fixe, et donc a chaque rafinement de la gravure, ca prend de moins en moins de place. Bon, apres, c'est de plu sen plus difficile de graver plus petit . l'EUV devrait aider.
 
La philisophie de ARM, c'est on n'implemente que les trucs qui marche super bien et qui ne consome pas trop.
La philisophie derriere le x86 (jusqu'a recemment), c'est on implemente tout ce qu'on peut qui peut aider meme un peu la perf (les optis des dernieres années suivent une philisophie plus ARMesque, mais reste tout le passé). A priori, en 10nm, le x86->RISC actuel ne devrait pas theoriquement etre un boulet pour le rapport perf/conso.
 
Globalement, la conso a qd meme bcp baissé les derniers années (mais au detriment d'une stagnation globale des perfs).

l'AVX entre toutefois bien dans cette philophie x86, cela permet d augmenter les perfs, mais au détriment de la conso.

Oui oui oui !

Ca dépend à quel TDP (x3) !

Oui pour le RISC interne sur x86, oui pour le frontend (a peu près) fixe (mais gros). Oui a 130/200W l'impact du frontend x86 est négligeable. Si on s'arrête là, on peut dire que CISC vs RISC c'est un faux combat ((c) Intel 2000).

Dans le monde moderne, sur une archi mobile, le gros frontend de x86 est un handicap important sur la consommation en charge faible où le frontend coûteux en ressources pompe significativement la batterie malgré les gros efforts pour le race to sleep (qui ont été massifs post Core 2 ou c'était catastrophique, Intel a été a peu près au bout de ce qu'il pouvait sur Skylake qui est un step massif sur ce plan). Voir l'oeuvre d'Intel a 1.5W pour voir le problème poussé à son paroxysme.

D'après des ingés qui ont bossé sur les 2 récemment, l'avantage d'ARM sur les TDP mobiles, à toutes autres choses égale, n'est pas négligeable.

 
C'est pas faux que 130W ou 5W, c'est pas le meme combat.
j'ai encore dans la tete mes cours de M2 (enfin DEA) d'archi, qui commence à remonter...

les commentaires de huang sur ces derniers jours

http://www.tomshardware.com/news/n [...] 35895.html

et il pense bien qu'intel rentre dans les gpu pour l'ia
"Huang's statement aligns with our thoughts that Intel's return to the discrete graphics industry is more centered on capturing some of the burgeoning use-cases for parallelized workloads, such as AI, than it is about gaming. Nvidia's push into the data center has been fruitful, as evidenced by the 109% YoY revenue growth, but it's really just the beginning of GPU penetration into several other segments, such as autonomous driving."

ensuite concevoir un gpu, c'est une chose, faire le soft derrière c'est aussi voire plus difficile

et je pense amha qu'intel n'arrivera pas à rattrapper 10-20 ans d'expérience gpu, donc la collaboration avec amd devrait ne pas s'arrêter à des kbg...

Bah non, si on veut du vectoriel il faut des gros caches pour pouvoir étaler/dérouler le travail et en éxécuter le plus possible par unité de temps.

Netburst avait pris l'approche des threads pipelinés (exécution série la plus rapide possible) donc l'exact opposé d'IA-64 qui visait à exécuter le plus possible de front), mais au final les 2 ont copulé et on se retrouve avec les archis Core.

Si je reprends les arguments d'époque pour IA-64, c'est amusant de constater que grossièrement Core = IA-64 + ce qui coûtait cher et n'était donc pas implémenté (mais d'où venait donc cette consommation de ouf du coup?). En fait, en étant mauvaise langue, on peut dire qu'il est vraisemblable qu'IA-64 tel qu'il nous a été vendu n'était pas ce qu'on retrouvait dans le silicium, qui était la seconde voie de l'époque (possiblement à l'image des PPC)... et si ça rappelle la comm d'AMD quand ils se chient dessus (les "optimisations" et autres "nouveautés" dont la présence est on ne peut plus transparente, bref les promesses non-tenues), c'est normal

 
on est d'accord. Du coup, penses tu qu Intel laissera un jour tomber ce gros front-end x86? Il reste la base de toutes les instructions simples, donc j imagine que c est pas facile.
 
D un autre côté, en baissant massivement la fréquence (32 Mhz), Intel sait faire du x86 équivalent Pentium à 0.025W, avec Quark qui sert de microcontrolleur pour certaines cartes et pour l AMT (management des PC éteints!):  
https://en.wikipedia.org/wiki/Intel_Quark
https://en.wikipedia.org/wiki/Intel [...] Technology
 
Intel pourrait donc imaginer de conserver une partie x86 ds ses CPU mais à une fréquence bien moindre que le reste des instructions! Quoique si toutes les autres instructions sont baties 'on top of x86', cela n'a peut etre pas de sens.

 
C'est avec ce genre de commentaire que l'on voit à quel point le métier d'ingénieur est désormais si peu considéré ...
On en arrive au point où les managers ont moitié moins de QI que les ingénieurs qu'ils encadrent, et je ne parle même pas des compétences !!!

On est arrivé à un époque où le marketing est roi et où nombres d'entreprises sont dirigés par des gestionnaires.(et donc mathématiquement voué à disparaitre à long terme)
Pourtant dans le mot entreprise il y a entreprendre. Durant les 100 derrières années on a découverts et créer nombre de choses formidable. Depuis 15ans c'est plutôt le calme plat. Intel en est le parfait exemple.
L'espoir n'est pas perdu, Elon musk arrive presque tout seul à sortir la Tesla, ridiculise la Nasa alors qu'ils sont pourtant bardés d'ingénieurs et doté d'un budget colossale... C'est là où tu dis qu'il y a vraiment un problème quelque part.
Au niveau informatique on en est encore à la préhistoire, quand tu vois ce que ça consomme sans avoir intelligence d'un simple lézard...
Mais ces grosses sociétés de semi-conducteurs sont en train à coup de milliards de créer une paraffine 5% plus durable pour leurs bougies. Voie de garage assuré.
Quant au X86, mon dieu...

Tuer le X86 très bien mais pour la remplacer par quoi ? Quelle architecture avec haute performance débarrassé de toute héritage passé peut le remplacer ? A par le PowerPC (rip) il n'y a pas eu masse d'archi plus moderne/performante que l'X86

A un moment faut juste revenir à la base : y'a quoi dans x86 qu'on ne retrouve pas dans les autres ISA et à quoi ça sert?
 
D'après ce que j'ai compris, pas mal des "optimisations" sont relatives à l'exécution dans un unique thread de code bourré d'appels avec passages de pointeurs, ceci dit j'ai pas encore eu la motivation pour aller voir à quoi ça ressemblait en asm.

@raven loft
Le x86 à 40 ans, mais on peut extrapoler l'âge de l'arm à environ 30 ans, c'est pas tant l'âge qui compte que la philosophie (il y a aussi au moins un mode legacy sur arm)

Mouais... j'ai été vérifier, et en dehors du fait que tout doit être "microcodé", y'a pas vraiment de souci avec le x86/x64. Après, je dois avouer trouver étrange qu'une instruction ne soit pas codée de façon similaire au VLIW, à savoir instruction à proprement parler + flags qui en définissent la variante dans un nombre de bits donné qui définiront la signification des "champs" restants (valeurs, adresses, registres).

 
Pas d'accord. Si Vega est un peu un pétard mouillé, AMD a montré avec leurs CPU qu'ils avaient un savoir faire technique. Ils ont l'air de s'être extraits de leurs probleme de fondeur et ont enrgangé les sous cette année, ils sont sur une bonne dynamique. Mon Pc me permet encore de ne pas changer de matosse cette année, j'aurais pu a la limite changer de CG mais les prix Nvidia je rentre pas dans la combine, c'est bien trop cher pour du matériel à courte durée de vie.

Non mais t’embête pas a répondre a ce troll en papier crépon hein

Le premier probleme chez intel qui daigne s interesser à qqs bug qu'une fois tout les 10mois
 
Avant de pondre u. Nouveau gpu chez intel, faudrait déjà arreter de prendre le client pour un con en passant au moins à 1 drivers correcteur de bug à un rythme d au moins 1 par trimestre, pour intel ça serait un pas de geant.... Et ça sans même parler de jeu video, rien que les bug graphique rencontré sur des notebook en entreprise sur de l applicatif