Reprise du message précédent :

+1
Quand ça discute technique c'est chouette. Quand ça part en guerre de trolls, ça l'est moins. Mais là c'est technique, c'est enrichissant, c'est ce qu'on aime sur HFR

 
comme le souligne un lecteur ds cet article, un autre parametre de la complexité du chip et de la perf/W, c est la densité possible de socket sur une carte. Sur les serveurs hautes perfs, c est surtout du RISC Sparc ou Power8 car les x86 sont limités à 8 sockets / carte.
Reste à voir ce que Qualcomm proposera...

Beaucoup plus large à quel point à cause de la rétrocompatibilité? Si on vire la rétrocompatibilité le front-end sera plus large mais pas beaucoup plus large non? Ce qu'on gagne en RISC sur les décodeurs on en perd une partie sur le bus et le L1i?
 

+15% juste sur les décodeurs ou sur le core? Sur un genre Quark ou plutôt Haswell?
 

A priori c'est les mêmes techniques pour ARM, donc à terme la pénalité sur le front-end pour le x86 devrait être diluée non?

Ca n'est pas que la rétrocompatibilité et virer des instructions qui pénalise, c'est toute la philosophie du jeu d'instruction qui est héritée des origines de x86 qui est dérivé du jeu d'instruction des premiers CPU 8 bits d'Intel, pensés uniquement pour l'assembleur à une époque ou on économisait les bits. C'est même au delà de RISC vs CISC, x86 est un cas à part.  
 
x86 n'a jamais été considéré comme élégant, y compris dans les années 80 face aux 680X0 de Motorola par ex. C'est avant tout un vieux design qui a un avantage massif pour la rétrocompatibilité (en grande partie grâce/a cause de Windows) mais si on partait d'une feuille blanche aujourd'hui, personne ne designerait quelque chose qui ressemble.  
 
Le débat RISC/CISC est effectivement toujours compliqué parce que les définitions ont changé. Les premiers RISC sont arrivés avec l'idée d'avoir un jeu d'instruction réduit (qui nécéssite donc plus d'instructions au total dans un programme), et toujours 1 cycle par instruction pour augmenter l'ILP. Ca a changé par la suite, avec quelques instructions sur plusieurs cycles et a l'inverse le CISC d'Intel a migré vers des micro ops. Résultat pour augmenter l'ILP chez Intel il faut un frontend massif, ce qu'ils font avec brio en passant.  
 
Il faut rajouter les MMX/SSE/AVX & co qui rallongent la liste d'instruction à chaque génération, quelque chose qui était utilisé par Intel comme un différenciateur commercial face à AMD (qui avait un SSE de retard souvent) pour des instructions rarement utilisées en pratique, vu qu'on compile rarement pour les derniers CPU uniquement pour sauver la rétrocomp. Le cout en transistors était minime pour un avantage marketing important (même si négligeable/nul pour un tas d'apps), mais ça crée au fur et a mesure une dette technique que le x86 porte, et qui n'arrange pas son affaire sur le low power.
 
C'est l'addition de tout ces facteurs, à mon avis, qui fait qu'Intel peine tant a percer sous les 10W. Le handicap est dur a combler, l'avantage d'Intel sur les process se réduit qui plus est ce qui n'arrange rien.
 
Pour faire un aparté sur l'utilisation du frontend pour tirer des performances, il faut dire que c'est un avantage notable sur les CPU a gros TDP vu qu'on ne peut plus simplement augmenter la fréquence pour aller plus vite. Pour revenir a la news, c'est pour ça aussi que l'on voit des nombres de coeurs massifs dans le sample de Qualcomm, et que l'on verra probablement des 32/64 coeurs dans les 2 ans, l'augmentation du TDP passera par un peu plus de fréquence possiblement, et beaucoup plus de cores. Il y a quelques années, beaucoup pensaient qu'ARM ne scalerait jamais en performances pour atteindre les perfs single core du x86, l'A9 prouve que c'est non seulement possible, mais avec un TDP encore plus bas. Est ce que la formule de l'A9 marcherait passé 10W ? 15W ? Pas dit, mais il n'y a pas si longtemps que beaucoup doutaient qu'ARM serait compétitif a 5W. Est ce qu'au final l'avantage d'ILP "by design" d'un jeu d'instruction plus court/moderne peut scaler correctement, ca sera une des questions brulantes des prochains mois je pense.
 

15% sur la conso totale moyenne. Les décodeurs et le gros du frontend sont arrêtés le plus vite possible (le frontend décode, stocke dans des caches, s'arrête pour minimiser l'impact conso).  
 
Plutôt sous Haswell mais pas si bas que Quark
 

Cf plus haut, by design il y a plus d'ILP naturellement chez ARM (je parle ici uniquement des implémentations d'Apple qui sont les plus intéressantes aujourd'hui). Il y a surement des idées a reprendre dans un frontend massif pour ARM pour augmenter les perfs quand on atteint la limite de la fréquence, peut etre avec une architecture encore plus wide mais est ce que la formule sera la même, loin d'être dit.

Très intéressant.
C'est vrai que les core ARM d'Apple sont impressionnants, ils prouvent qu'on peut atteindre le taux d'IPC d'un core x86 récent avec du ARM.
Mais d'un autre côté ils ont vraiment été conçus pour être le plus performant possible sur ce genre de TDP très petits.  
Alors que les tentatives d'Intel sur le low power, c'est plutôt des essais pour faire fonctionner une architecture pas prévue pour ça à basse consommation.
 
Donc difficile de savoir si sur des très gros CPU avec des gros TDP, un CPU ARM (type Apple par exemple) serait aussi efficace qu'un CPU x86.
C'est pour ça que je vois pas ARM s'imposer de si tôt dans l'informatique haute performance (PC de jeux, Supercalculateurs etc...)

Les gens, juste merci d'avoir autant commenter. J'ai doublé mes connaissances sur le fonctionnement d'un cpu en 45min !

Tu as d'un coté intel qui veut faire du low power avec une archi qui n'est pas faite pour.(si tenté qu'on puisse appeler en 2015 ce sac de noeud, archi)  
Et de l'autre Arm, qui veut faire du highpower avec une archi qui est faite pour l'inverse...
 
On va attendre un compétiteur qui saura utiliser les techniques pour ce à quoi elles sont prévus, un nouveau Motorola?

pour l'instant c'est l'applicatif qui impose.
si du jour au lendemain on m'annonce que je vais devoir repayer pour tout ce que j'ai, que la plus part de ce que j'ai ne sera tout simplement pas utilisable, ca va avoir du mal a passer la pilule.
 
je me souvient plus trop comment c'est passé la transition vers intel pour les MAC.

A la décharge d'Intel, ils ont essayés de pousser Itanium (IA-64) pour se débarrasser du x86 mais ça n'a pas pris.
 
C'est effectivement surtout côté applicatif (MS) que ça coince. Il n'y a eu que des versions de Windows Server qui le supportaient.

Windows XP 64 était d abord pour l IA-64, la version x64 est arrivée plus tard. Ca n a durer que 2-3 ans, qd HP a arreter de faire des worksation Itanium.
( https://en.wikipedia.org/wiki/Windo [...] it_Edition )
Mais c est surtout que le EPIC/VLIW du IA64 s est averré bcp plus complexe que prévu, surtout pour les compilateurs.
Donc bien le manque d appli; mais pas lié à l OS: fiasco aussi bien en Linux/Unix qu en Windows.
l Itanium est enterré depuis qques mois, HP vient de tourner tous ses serveur HighPerf en Xeon.
https://en.wikipedia.org/wiki/HP_Integrity_Servers

je pense pas que ce soit "que" la faute a MS, le version serveur de windows a bien pris le pas sur la partie Home (le kernel NT a tué windows 9x)
 
il aurait sans doute nécessité de refaire des drivers pour tout, refaire tout les applicatifs,...

Plutôt bien.  
 
Côté utilisateur c'était transparent, les softs PowerPC fonctionnaient as is sur Mac x86, avec une couche de traduction dynamique ( https://en.wikipedia.org/wiki/Rosetta_%28software%29 ). La pénalité de performance était variable selon les apps mais pour une période de transition, sachant que les CPU x86 (Core 2) étaient plus rapides que les (très vieux) PPC qu'ils remplacaient, c'était satisfaisant.
 
Pour les développeurs tout dépendait de ce qu'ils utilisaient puisque Apple a l'époque sortait d'une autre transition (Mac "classic" vers OS X en 2001? La transition PPC->x86 2006 de tête ?). Pour ceux qui avaient porté leurs applications, ils pouvaient assez facilement recompiler, Apple utilisant des binaires fat (quand on compilait, on générait le code à la fois pour PPC et x86) pour que ca soit transparent pour l'utilisateur (un seul exe indépendamment du type de Mac).  
 
Le problème était pour les développeurs qui utilisaient encore les API de compatibilité avec le Mac des années 90 (typiquement Photoshop), pour eux, la marche était plus importante mais ça n'avait rien à voir avec le jeu d'instruction, c'est juste qu'il fallait qu'ils réécrivent leur interface graphique pour MacOS X, ce qu'ils n'avaient pas fait jusque là.
 
Aujourd'hui il y a encore des binaires fat chez Apple, les applis iOS sont compilés pour armv7 (32 bits) et armv8 (64 bits), voir même des variantes pour un CPU précis. C'est transparent pour l'utilisateur, ca fait des binaires plus gros mais ils sont découpables (ce que fait l'App Store qui n'envoit désormais que le binaire pour le device). Et de la même manière quand on utilise le simulateur iOS sur Mac, on fait en pratique tourner une version d'iOS sur x86, le compilateur compilant nativement le code pour x86 pour son utilisation dans le simulateur. Apple peut donc demain décider de faire des iPhones x86 (:D) ou des Mac ARM (ou autre jeu d'instruction) sans trop de difficulté si c'est leur envie.
 
Changer de jeu d'instruction, ou en supporter plusieurs en simultané n'est donc pas trop un problème que ce soit avec les langages compilés ou les trucs plus récents (Java/.NET, qui déportent la fin de la compilation sur le device au moment du premier lancement). C'est d'ailleurs la voie utilisée par Microsoft dans Windows 10 pour les "universal apps" qui tournent à la fois sur des smartphones ARM et des PC x86, c'est du .NET tout simplement.  
 
Ce que Microsoft n'avait pas fait sinon pour Windows RT, c'est autoriser la crosscompilation x86 et ARM de code C/C++ (alors que c'était prévu a l'origine), ou instauré un quelconque format de binaire fat. Sans ça, toutes les applis C/C++ (les jeux et la majorité des applis) n'avaient aucune chance de tourner sur ARM vu que les devs ne pouvaient pas compiler d'apps natives. Autant dire qu'ils n'avaient pas envie que ça prenne.

on peut ecrire les "universal apps" en .NET mais cela s appuie sur WindowsRuntime/WinRT ( https://en.wikipedia.org/wiki/Windows_Runtime) écrit en C++ qui remplace Win32 en C. WinRT est la couche entre l OS et les App et dispo aussi bien sur x86 que ARM, donc la partie applicative ne devrait pas etre un soucis pour les nouveaux CPU Qualcomm; d autant que les ARM des WindowsPhone Lumia sont exclusivement des Qualcomm.

Sois sûr que ton ex-confrère Anand fait tout ce qui est en son pouvoir pour ça arrive  
 

Vu le dernier iMac 21" ils semblent s'y diriger. Le problème Windows/BootCamp reste quand même épineux.
 

J'aimerais avoir raté un truc, mais aujourd'hui on ne peut toujours pas compiler "nativement" sous ARM comme avec Win32? On est obligé de passer par l'Universal Binary avec une manip dans ce genre?  
https://msdn.microsoft.com/en-us/library/mt186162.aspx
 
Et dans les faits, malgré ce qu'a pu dire Microsoft, on a toujours 2 Windows : Le "vrai" Windows uniquement sous x86, et la réincarnation de RT sous la forme de Windows Mobile, où les seuls trucs qui tournent sur ARM sont les Universal Apps?
 
( Pour être honnête je n'ai pas encore essayé de développer une Universal App. Peut-on utiliser les API comme wxWidgets, libusb-win32, Bluetooth comme sous Win32 et faire autre chose que des applis de tablette ou de bureautique? )

cf plus haut, WinRT, a vocation a remplacer Win32 dans la vision Microsoft. Donc in fine, ARM ou x86, ce sera transparent pour les app.
 
Par contre, j ai l impression que WinRT est encore loin de la stabilité et maturité de Win32 (au top avec Win7 AMHA), je trouve que les "metro app" de Win10 crashent trop souvent. Regardez l observateur d evenements de Win10, le nbre d erreurs me semble bien superieur à ce qu on avait sous Win7.

 
Et n'oublions pas pour ces extensions, les encodages VEX, introduit pour AVX, et EVEX pour AVX512, histoire que ça ne soit pas non plus trop simple pour les développeurs d'assembleur/compilateur.

Bien vu merci, je n'avais pas suivi ! En pratique ça donne quoi une app native C++ ARM et x86, des binaires séparés dans un bundle ? Je n'arrive pas a trouver grand chose sur le sujet.  
 

Même chez Intel ils se sont fait une raison sur la question ! Je ne pense pas qu'ils aient encore complètement digéré la "trahison"...
 

Avec la virtualisation aussi oui, mais difficile de savoir quel pourcentage des utilisateurs en dépend.  
 

Comme beaucoup de monde
 
Je n'ai pas trouvé de réponse claire sur comment était géré tout ca, mais visiblement on peut compiler natif arm désormais : https://ffmpegwinrtarm.codeplex.com/
 
J'ai cherché vite fait plus d'infos mais pas trouvé grand chose sur la manière dont tout ca est censé fonctionner en cross plateforme quand même.

 
Erf, c'est surtout Intel qui n'a pas assuré pour le coup vu qu'Apple les avait approché pour la fabrication du Soc du premier iPhone.    Bon, ils peuvent encore se rattraper, il parait qu'Apple hésite entre un modem Qualcomm et un modem Intel pour ses prochains smartphone  

 
Explication rationnelle à cela ? Gueguerre entre divisions chez m$ ? Vraie question, je connais très mal le monde win. Pour ce que tu as décrit en matière de transition PPC/X86, il n'en étaient pas à leur coup d'essai chez apple. Ils avaient fait exactement la même chose lors de la transition motorola 68K/PPC.  
 
J'ai encore de vieux macs avec des binaires FAT 68k/PPC qui fonctionnent très bien. Le seul problème est qu'ils n'émulaient pas le coprocesseur math des 68k.

Aucune, a part vouloir planter le produit a mon avis mais comprendre la logique de Microsoft est souvent compliqué. En théorie du complot on peut blamer Wintel sinon C'était d'autant plus ridicule qu'Office était lui une app desktop pour Windows RT, app native compilée ARM. Mais personne d'autre n'y avait droit.  
 
Et oui Apple n'était pas a sa première (ni sa dernière) transition, de nos jours ils maitrisent complètement le sujet

c est surtout que MS ne sait sans doute pas lui meme ce qu il veut. c est arrivé assez souvent qu ils aient des stratégies contradictoires d une version à l'autre de leurs produits...

Ce ne sont pas les russes et chinois( armées) qui ont décidé de créer un super calculateur à base de puce ARM sans aucun matériel sous licence américaine