L'architecture ARM ne peut encore remplacer l'x86, regrette Linus Torvalds
L’architecture ARM n’est pas encore en mesure de prendre la place de l’architecture x86 d’Intel. C’est le constat qu’a dressé Linus Torvalds alors qu’on l’interrogeait sur celle qui avait sa préférence.
Le développeur et créateur du noyau Linux intervenait il y a quelques jours à la conférence Linaro Connect de Las Vegas (son propos arrive vers la 21e minute de la vidéo).
Depuis un certain temps déjà, des indices laissent à penser qu’Apple pourrait à nouveau changer de cheval. Abandonner Intel et faire pour le Mac ce qu’elle a fait pour ses iPhone et iPad : prendre en main le destin de ses processeurs, ne plus dépendre du calendrier d’Intel et de ses aléas, pour développer ses puces sur la base des designs imaginés par ARM.
Torvald a une véritable affection pour cette autre architecture qu’il a pratiqué à la fin des années 1980. Après s’être fait la main sur la famille 68000 de Motorola et le processeur 6502 en particulier, il a tenté l’aventure avec l’Archimedes d’Acorn.
Cette famille d’ordinateurs avait cela d’inédit qu’elle s’appuyait sur un processeur ARM de type RISC (à l’instar des PowerPC plus tard). C’est cette puce qui donnera naissance en 1990 à la société britannique ARM, constituée par Acorn Computer, VLSI Technology et Apple (en vue d’équiper son Newton).
Les Archimedes, bien que novateurs et puissants, n’ont pas connu un très grand succès en dehors des écoles britanniques et d’un cercle de passionnés. Torvalds est alors passé sur le QL de Sinclair — famille de processeurs 68000 — mais ce fut un autre échec commercial.
Linus Torvalds en est ressorti vacciné et en a tiré une leçon : « Ne jamais, ô grand jamais, investir dans quelque chose qui n’a pas derrière lui le soutien d’une infrastructure ». Ce n’est pas tant une histoire de jeu d’instruction meilleur qu’un autre, dit-il, mais de l’existence d’un « écosystème » solide autour.
30 ans après la disparition des ordinateurs d’Acorn, il n’existe toujours pas de plateforme de développement basée sur une architecture ARM, se désole Torvalds : « J’adore le concept ARM et cela me déçoit profondément ».
Aujourd’hui, les développeurs conçoivent toujours leurs applications sur des ordinateurs basés à processeurs x86. Tout en louant les vertus pédagogiques pour les jeunes de ce « jouet » qu’est le Raspberry Pi — construit avec un processeur ARM — il observe que là aussi il faut un PC x86 pour développer dessus.
« C’est un gros, gros problème et ARM ne pourra pas gagner tant qu’il ne lèvera pas cet obstacle » avant de conclure en riant « Et j’ai toujours raison ».
Apple, à ce titre, est bien placée pour tenter de répondre à ce challenge. Elle s’appuie sur des designs ARM pour ses Ax et conçoit en parallèle les ordinateurs utilisés pour développer des apps iOS. En décidant un jour de basculer ses Macintosh sur une architecture ARM elle serait en mesure, peut-être, d’exaucer enfin le vœu de Torvalds…
Si Apple passe à l'ARM pour ses Mac, est-ce que cela signifie que les applications actuelles devront être adaptées pour être nativement compatibles ? Est-ce que Apple permettra l'exécution de programmes Intel sur les nouvelles machines à l'aide d'un émulateur (comme ils l'ont fait avec Rosetta) ? Affaire à suivre...
@Nicolapps :
Oui les applications devront être adaptés pour l'architecture ARM, mais si les applications ont été développées en utilisant Xcode et en Objective-C/Swift alors la moitié du travail à déjà été faite. (C'est valables pour 75% des applications, pour certaines il y aura besoin d'un peu plus de travail).
@Dark-mac :
C'est justement ce que j'allais dire, ça fait bien longtemps qu'Apple prépare le terrain avec son langage Swift qui rend va rendre la transition transparente. Sachant que Swift ne se limitera pas au seul écosystème d'Apple, plein de développeur seront coder aussi sur et pour des architectures ARM et x86
Oui et surtout que ça permettra de faciliter les portages d'apps ou de jeux entre iOS, macOS et tvOS.
@Dark-mac :
Pas vraiment
@Dark-mac
Il faut distinguer 2 choses:
- l'architecture de la machine
- l'interface et l'usage de la machine
Il est certain que plus on utilise un environnement de programmation de haut niveau et qu'on respecte les normes et standards du systeme de developpement, moins le passage d'une architecture processeur a une autre represente une difficulté.
iOS c'est MacOS a 95%. Reste donc les 5% qui represente l'interface et la telephonie.
Bref pour le developpeur, la question de l'architecture ne se pose pas dans la grosse majorité des cas.
Par contre ce qui pose un gros probleme c'est l'interface graphique et la conception de l'application pour cette interface. C'est pas qu'une question d'apparence, c'est une question d'usage. Concevoir une application pour un mobile tactile c'est tres different d'une application pour un PC pensé pour le clavier et la souris.
Il y a aussi la nature des applications qu'il faut prendre en compte.
Sur mobile on fait des applications de consultation de contenus pas de production. L'interface doit etre minimaliste, tres reactive, les fonctions doivent etre tres limitées. L'usage se fait en mobilité.
Sur PC on peut developper des applications de creation tres complexes, avec des interfaces elaborées et penser a un usage dans un bureau.
Si on considere le jeu, celui sur mobile doit être conçu pour etre executé en mobilité, en temps court et fractionné avec juste l'ecran et le gyroscope comme controles.
Sur PC on pense a l'utilisateur dans son salon qui va jouer pendant des heures non stop avec un ensemble de controles variés (clavier, souris, joystick et autres manettes, kinect,...)
Celui qui sait developper sur mobile ne sait pas developper sur PC et inversement. Le portage d'une application d'une plateforme a l'autre necessite une reconception de la logique d'usage. C'est la difficulté.
Swift et les API vont beaucoup aider, mais c'est pas si simple.
@C1rc3@0rc
"iOS c'est MacOS a 95%. Reste donc les 5% qui represente l'interface et la telephonie."
Tu parles de quoi ? de la proportion de code commun au deux OS ?
Tes chiffres me semblent très fantaisistes
@@C1rc3@0rc
"Par contre ce qui pose un gros probleme c'est l'interface graphique et la conception de l'application pour cette interface."
Mais cette question ne se poserait nullement au sein d'un même OS supportant des processeurs différents.
C'est là totalement transparent pour le code.
Je crois que tu n'as pas compris.
Un soft c'est un processus de traitement d'un ou plusieurs type d'informations et une interface pour interagir avec l'utilisateur.
Tu peux avoir une interface de type ligne de commande, une interface graphique a base d'icones et symbole de controle et feedback qui se manipule a la souris, une interface tactile qui mele le controleur et l'affichage (ecran tactile), une interface pour la VR,...
Le programme de traitement de l'information c'est la partie mathématique et automatique.
L'interface utilisateur c'est ce qui rend le traitement contrôlable par un utilisateur.
On peut avoir le meme traitement sur 2 appareils distincts, l'un a interface souris+icone et l'autre une interface ecran tactile.
Si la partie traitement reste alors la meme, la conception des interfaces est totalement différentes.
Rajoutes a cela la dimension "mobile" dans un environnement requerant de l'attention (qu'on peut dire hostile) et tu comprends que concevoir une application pour iOS et MacOS c'est deux processus differents et specifiques.
Un programmeur iOS n'a ni les memes priorités ni la meme approche qu'un programmeur MacOS ou Linux. En fait il est plus facile de porter un programme Linux sur MacOS qu'un programme MacOS sur iOS (pour peu que ça ait un sens)
L'ignorance puis la tentative d'automatisation impliquée par la différence de l'interface graphique c'est la tres grosse erreur de Microsoft depuis Windows 8 avec Metro. Le meme soft qui fonctionne sur une tablette et un PC est un non sens absolu.
Le moteur de traitement, requière des compétences d'ingénieurs et de mathématiciens. L'interface requiert des compétences en ergonomie cognitive.
@C1rc3@0rc
"Je crois que tu n'as pas compris.
Disons plutôt que nous ne nous sommes pas compris.
Au vue de ce que tu veux m'expliquer dans ton commentaire qui tient de l'évidence sur quasiment tous les points ;-)
@C1rc3@0rc
Pour le reste ta vision de la dichotomie entre interface WIMP et Multitouch me semble fortement biaisé par ta propension à croire que rien de sérieux ne peut se faire sur la seconde.
"Sur mobile on fait des applications de consultation de contenus pas de production. L'interface doit etre minimaliste, tres reactive, les fonctions doivent etre tres limitées. L'usage se fait en mobilité.
Sur PC on peut developper des applications de creation tres complexes, avec des interfaces elaborées et penser a un usage dans un bureau.
C'est assez obsolète comme vison et tout autant daté.
Parce que pour toi une application de consultation, de navigation, d'organisation, de recherche dans un flot d'information c'est pas sérieux?
Faudrait que tu commences a concevoir que le travail d'analyse et la prise de decisions se font d'abord par la consultation et la mise en relation d'informations.
Sans parler que ce qui genere aujourd'hui le maximum de valeur financiere c'est la consultation s'information, sa consommation par des outils informatiques! Et cela que ce soit dans les domaines du divertissement GP ou professionnel grand compte...
Ensuite, réaliser une interface efficace et pertinente c'est le point crucial qui demande un travail et des compétences conséquentes. Tu peux bien avoir le meilleur moteur de traitement d'information, si la présentation et la manipulation de l'information sont déficientes, le programme vaut juste le prix de son moteur, s'il peut etre racheté!
Faut se rendre compte qu'on est plus dans les annees 70 et qu'on est quasi tous amené a manipuler des informations toujours plus complexes et volumineuses sans pour autant etre informaticien pro.
Meme madame Michu aujourd'hui utilise plusieurs ordinateurs sans avoir la moindre formation et c'est elle qui genere de la valeur financiere, sans rien creer et juste en consommant.
L'interface d'une application est aujourd'hui le point le plus crucial. Meme et surtout si c'est pour de la consultation de divertissement très grand public.
C'est cette idee d'ailleurs qui a fait le succès d'Apple et qui pendant longtemps a ete le mantra d'Apple sous Jobs.
@C1rc3@0rc
Là je n'aurait qu'une seule réponse : WTF ?
Ton commentaire n'a strictement rien à voir avec mon propos, j'ai sans doute manquer de clarté.
Pour le reste je ne crois pas qu'il y est une énorme différence de connaissances théoriques entre nous, pas la peine d'essayer de m'expliquer des base ;-)
@C1rc3@0rc
Oui, très fantaisistes tes chiffres !
Pourquoi?
@Pourquoi?
Avancer à la cantonade :
""iOS c'est MacOS a 95%. Reste donc les 5% qui represente l'interface et la telephonie."
C'est quand même franchement questionnable
Dans ce sens là, c'est possible. Le problème, c'est plutôt que c'est faux dans l'autre sens : osX n'est pas 95% d'iOS. Dommage, c'est le sens qui aurait permis de poser les macs sur ARM.
Et dans iOS ce qui a été retiré est justement ce qui demande une architecture plus polyvalent et puissante (multitâche, multi user, ...)
A mon avis Apple a identifié tout ca et profite de l'iPad pro pour refaire ces parties de façon plus moderne.
ie: le mac ARM arrivera après l'iPad multi utilisateur, multitâche, avec la possibilité d'en faire un serveur (deamon, gestion des ports, routage ...) etc.
@Un Type Vrai
"ommage, c'est le sens qui aurait permis de poser les macs sur ARM."
Le portage d'un OS moderne sur une architecture est bien moins complexe aujourd'hui que tu ne veux le croire.
Il est quasi certain qu'Apple dispose déjà en interne d'un macOS sous ARM.
Ce n'est en rien un défi technique monopolisant de gros moyens et de nombreuses ressources ;-)
@C1rc3@0rc :
« … environnement de programmation de haut niveau … developper des applications de creation tres complexes, … »
Il n'y a pas de langage qui n'ai son équivalent
Graphique et vis versa
puisque cela revient exactement au même !
Un langage de « haut niveau » aussi précis que soit sa vocation peut être concis … autant que peut l'être un trait. On parle bien de la — puissance — du langage et du symbole.
Si je trace l'exposant ou l'exponentiel dans mon programme fonctionnel pour cette « création très complexe », c'est plus l'expressif et court …
Presque(partout) exp(plosif)
Difficile d'imaginer qu'PC puisse dialoguer avec un tableau noir, une feuille à dessin … pour tout programme que cela vaille finalement.
@LoursonMignon
Tu surestime de beaucoup la portée de Swift dans l'équation
Par contre les approches LLVM récemment introduites par Apple pourrait prendre encore plus de sens dans le cadre d'un support de plusieurs architecture matériel
A ce niveau on a deja un tres haut niveau d'abstraction. La plupart des applications ne font que des appels aux API et ne "touchent" jamais le jeu d'instructions du processeur, ni meme les composants de la machines.
Swift est un pas de plus vers l'abstraction et l'independance envers le materiel.
Dans la majorité des cas passer d'une application MacOS Intel a MacOS ARM ou autre se resume a appuyer sur 2 controles pour le developpeur.
Si on revient aux propos de Torvald ce dont il parle était une réalité des années 80, pas d'aujourd'hui. Il ne mentionne d'ailleurs pas un element contre lequel il s'est énormément battu et ou il a échoué magistralement: la lutte contre le monopole Wintel.
Linux et le libre ont gagné sur beaucoup de secteurs informatiques, sauf sur le PC et le mobile. Aujourd'hui si la majortié des serveurs et des infrastructure tournent avec du Linux et du libre, les PC c'est 88% de Windows, 10% de MacOS et 2% de Linux.
Le mobile c'est iOS et Android, pas de linux!
Pourtant, techniquement, Linux est tres adapté autant pour le PC que le mobile...
La ou il a raison c'est que ce qui pose probleme pour l'arrivé d'ARM sur le PC c'est le commercial et le marketing.
Microsoft peut sortir du jour au lendemain Windows ARM.
Apple peut sortir MacOS ARM la semaine prochaine.
Linux ARM existe depuis des lustres.
Mais Apple ne sortira un Mac ARM que lorsque le meme processeur pourra aller dans un Mac ou un iPad. Apple commandera 350 millions de processeurs aux fondeurs, les meilleurs iront dans les Mac, ceux avec quelques defauts dans les iPhone et iPad, les plus proches du dechets iront dans les Apple TV, avec les core desactivés, la frequence abaissé,... bref comme le font Intel, AMD ou Nvidia et le reste de l'industrie. C'est une question de rentabilité et de marges sur du volume.
L'industrie PC est dans l'expectative et cherche un relai de croissance, n'investissant pas sur le PC, mais sur des conneries IoT...
@C1rc3@0rc
"Swift est un pas de plus vers l'abstraction et l'independance envers le materiel."
Là je ne te suis pas du tout, en quoi est-ce un pas de plus vers l'abstraction par rapport aux autres langages de haut niveau habituellement mis en oeuvre sur les machines Apple ?
La plus part du code pro suit pour les environment Apple est de l'Objective-C dont on ne peut pas dire que le niveau d'abstraction soit particulièrement au raz des pâquerettes
Pour toi la gestion de la memoire c'est du haut ou du bas niveau?
@C1rc3@0rc
Un langage de haut niveau doit rendre la gestion des questions d'allocation mémoire le plus transparente possible pour le dev.
C'est ce que fait Swift effectivement et c'est ce que fait avec les limites qu'on connait Objective-C et c'est ce que visent la quasi totalité des langages modernes.
Tes propos précédent laisse croire que toute les approche objet qui ont pu être battît sur la base du C sont des merdes ineptes par construction, ce qui est théoriquement défendable mais pratiquement caricatural.
@C1rc3@0rc
"Si on revient aux propos de Torvald ce dont il parle était une réalité des années 80, pas d'aujourd'hui. I"
Nous sommes bien d'accord sur l'obsolescence de sa vision qui est pour moi très datée
@C1rc3@0rc
"Mais Apple ne sortira un Mac ARM que lorsque le meme processeur pourra aller dans un Mac ou un iPad. Apple commandera 350 millions de processeurs aux fondeurs, les meilleurs iront dans les Mac, ceux avec quelques defauts dans les iPhone et iPad, les plus proches du dechets iront dans les Apple TV, avec les core desactivés, la frequence abaissé,... bref comme le font Intel, AMD ou Nvidia et le reste de l'industrie. C'est une question de rentabilité et de marges sur du volume.
Là part contre ça tient assez mal la route, Apple vie déjà fort bien le fait de ne pas avoir les même version de CPU ARM sur ces different produits.
Les volumes sont très largement suffisant pour que la "fonte" d'un ARM dédié à des Mac soit parfaitement rentable.
Le ressorts de ta vision ici ne tient pas un instant, pour moi
A part pour le gadget de moment qu'est l'Apple Watch, il n'y a q'une architecture ARM par génération chez Apple.
Le fait d'avoir plus ou mois de core ne change rien a cette complexité. Apres les anciens produits toujours maintenus ont des versions anciennes de son architecture ARM, mais au niveau exécution a part la variation entre le 32 et le 64 bits, c'est transparent.
Sur une années Apple va commander entre 250 et 300 millions de processeurs a ses sous traitants. Ils vont aller dans les iPhone, iPad et Apple TV. Soit ce sont des processeurs d'une meme génération, au fabricant de se charger de mettre n core en fonction de la destination, voire ils sont tous commandés avec le meme nombres de core et a la sortie ceux pour l'Apple TV voient un core désactivé, soit ce sont des anciennes générations, bien maitrisées et de toutes façon compatible entre elles.
On est tres loin des acrobaties d'Intel, avec des fonctions a tiroirs, et autres spécificités artificielles de famille.
Donc d'un coté on a entre 250 et 300 millions de processeurs iOS et de l'autre coté on a entre 15 et 20 millions de processeur MacOS.
15 millions c'est rentable en effet, mais certainement pas selon les niveaux de marges d'Apple et que permettent 300 millions d'unité.
Imagines en plus les specificité de l'A10x qui aurait pu etre produit en meme temps que l'A7 ( a part la finesse de gravure c'etait possible) on va dire en 6 core pour equiper un Mac. Ça aurait couté combien pour quel resultat.
Pour Apple mettre un A10x dans un iPad ou dans un Mac ça veut dire commander 60 millions d'une meme architecture avec juste une variation du nombre de core, sur une masse de 350 millions... T'imagines les leviers commerciaux sur les prix que ça permet. Les fondeurs qui recuperent cette commandes ont leurs valorisation d'assuré et leurs carnet de commandes pleins.
@C1rc3@0rc
"A part pour le gadget de moment qu'est l'Apple Watch"
Tu as réussi à le placer c'est bon tu n'as pas perdu ta journée :-)
Pour le reste c'est du grand n'importe quoi.
Les divers CPU des iPhone ne sont pas issu d'un même die, l'économie d'échelle que tu met en avant repose sur du vent.
Apple fait déjà produire déjà une grand diversité de die différent basé sur l'architecture ARM pour ces différent produit.
Il y a des moments où je me demande comment tu peux tomber dans des trucs de ce type ?
PS :Il manque quand même une pique rageuse sur le MacBook.
Je ne vois pas trop ce que Swift a à voir. Swift, comme l'Objective-C ou le C peut être portable au niveau source, mais il se compile en code machine au travers de llvm.
Les meilleures puces ARM commencent peut-être à rivaliser avec les processeurs x86 basse-consommation (Core M et consort), par ailleurs décriés par leur manque de vaillance dans les Mac Mini et iMac, mais on est encore loin de voire poindre des remplaçants de Core i7 sans parler des Xeon.
Surtout que pour pouvoir faire tourner des applications x86 dans un émulateur, il faudrait des CPU beaucoup plus puissants (ce qui était le cas des Xeon et Core des années 2006 comparés aux PowerPC des générations précédentes).
@fiatlux
"par ailleurs décriés par leur manque de vaillance dans les Mac Mini et iMac"
Décriés par un microcosme absolument pas représentatif des réalités du marché, donc cela n'a aucune importance :-)
@fiatlux
Ce que Swift change par rapport aux dérivés du C c'est le niveau d'abstraction. Le C implique toujours a un moment de devoir connaitre la gestion de la memoire et des techniques d'optimisation qui vont avoir un impact sur l'architecture. Gerer le parallélisme en C est une horreur parce que ce langage est construit sur le modele sequentiel des annees 70.
Les differentes couches rajoutées au C ne sont jamais unifiées et coherentes et on a toujours le modele primaire sous-jacent a prendre en compte. Et moins on le fait et moins on passe de temps dessus et plus on a des bug graves et des failles difficiles a reparer.
Avec des langages de haut niveau comme Swift ou de tres haut niveau comme Haskell le programmeur pense a la logique mathématique, pas au jeu d'instructions ni meme a l'architecture de la machine.
Au niveau des puces elles mêmes, il y a une différence fondamentale entre le x86 et ARM: un etage de traitement en moins du coté ARM, qui mécaniquement rend la puce plus efficace. A frequence égale les ARM sont mécaniquement plus performants que le x86, mais aussi plus plastique.
La ou il y a un gros avantage pour Intel c'est que les x86 demandent moins de travail aux développeurs des OS et des compilateur que les ARM. C'est toute la différence entre un CISC comme le x86 et un RISC comme l'ARM. Dans le RISC l'optimisation se fait a la compilation, dans le x86 c'est la cuisine interne dans le processeur.
Faut rappeler une chose: Intel a échoué techniquement et commercialement avec l'Atom. Le x86 consomme et chauffe de manière dissuasive. C'est inéluctable.
Niveau puissance le x86 stagne depuis 7 ans et niveau efficacité énergétique la dernière amélioration a été le passage de 32 a 22nm.
Aujourd'hui les ARM sont taillés pour le mobile, et pourtant ils ont la meme puissance que les Core i3 et Core i5 et tiennent sur la duree, pas question de bidouillage marketing au turbo!
L'emulation est un faux probleme et un epouvantail.
"Au niveau des puces elles mêmes, il y a une différence fondamentale entre le x86 et ARM: un etage de traitement en moins du coté ARM, qui mécaniquement rend la puce plus efficace."
Euh, non... D'abord, le nombre d'étages n'est pas le même sur tous CPU x86 ou sur tous les CPU ARM. Le nombre d'étages n'est pas une question d'architecture, mais une question de micro-architecture.
Ensuite, les puces ARM les plus complexes aujourd'hui (et notamment celles d'Apple) ont parfois plus d'étages que des puces x86. L'Apple A9 par exemple, il a un pipeline à 16 étages, alors que le Skylake a un pipeline a 14 à 19 étages, selon l'instruction, et que les Atom actuels ont eux aussi un pipeline à 16 étages.
Enfin, il n'y a pas de corrélation directe entre le nombre d'étages et la performance. Augmenter le nombre d'étages fait certes augmenter le temps qu'il faudra pour traiter une instruction, mais comme le pipeline se rempli au fur et à mesure (quand une instruction passe d'un étage au suivant, l'instruction suivante arrive dans l'étage qui vient d'être quitté), la profondeur de pipeline ne change rien au débit d'instructions. Là où ça va changer, c'est quand on commence à faire de la prédiction de branchement, puisqu'un échec de prédiction va coûter plus cher avec un pipeline a plus d'étages.
"A frequence égale les ARM sont mécaniquement plus performants que le x86, mais aussi plus plastique."
Là encore, c'est du n'importe quoi, puisque ça voudrait dire que les performances ne sont qu'une question d'architecture et de fréquence, alors que c'est avant tout une question de micro-architecture.
Or, rien qu'entre une puce ARM et une autre, on peut observer des écarts de performances monstrueux à fréquence égale. Quelqu'un qui s'intéresse aux produits Apple devrait particulièrement le savoir, puisque les puces ARM d'Apple sont régulièrement les plus performantes dans les tests, alors qu'elles sont souvent celles qui ont les plus faibles fréquences...
(suite)
Ensuite, ne tenir compte que de la fréquence, c'est oublier l'importance du premier C de CISC. Avoir des instructions plus complexes gérées directement par le CPU, en s’affranchissant du dogme "toutes les instructions doivent avoir la même durée de traitement" du RISC, ça permet de faire certaines opérations complexes bien plus rapidement que si on devait les faire avec une séquence d'instructions simples. Il y a par exemple sur le CPU x86 actuels une instruction très complexe, qui fait des opération sur une matrice 8x8 (utilisé en compression vidéo notamment) en quelques cycles, alors que l'équivalent en instructions simples nécessiterait plusieurs dizaines de cycles. Sur ce type d'opérations, je peux t'assurer que même le meilleur des CPU ARM n'arrivera pas à la cheville du plus petit des Core i3 à fréquence égale...
"Le x86 consomme et chauffe de manière dissuasive. C'est inéluctable.
Niveau puissance le x86 stagne depuis 7 ans et niveau efficacité énergétique la dernière amélioration a été le passage de 32 a 22nm."
Là encore, tu ressors des vieilles rengaines complètement éculées. Les CPU Intel d'aujourd'hui non strictement rien à envier aux puces ARM au niveau de l'efficacité énergétique.
Les puces ARM ont encore un petit avantage sur le très basse consommation, mais à l'inverse, elles se prennent une raclé sur les puces hautes performances. Regarde par exemple les comparatifs d'efficacité énergétique entre les plateformes serveur à base de Xeon D et leurs concurrentes à puces ARM... Et si tu ramènes l'autonomie du Macbook Retina à la capacité de sa batterie et fait la comparaison avec l'iPad Pro, tu verras que la consommation globale des deux machines est très proche, malgré pas mal de choses qui ne jouent pas en faveur du MB (mémoire, SSD PCI-E, etc...).
Parce que pour monter en performances, les puces ARM ont dû énormément se complexifier. Il y a besoin de plus de transistors aujourd'hui pour 1 cœur ARM Apple que pour 2 cœurs Atom...
@SartMatt
Sur la question des architectures CPU, C1rc3@0rc a des visitions très tranchées et inattaquables.
Un étrange mélange de vraies connaissance et de pensées magiques, plutôt rare.
Bon a part le nombres d'idioties dogmatiques de SartMatt, apotre du x86, que tu synthetises fort bien et de maniere peremptoire, faut expliquer 4 choses:
- pourquoi le x86, modele CISC, survit uniquement grace a son moteur RISC depuis le Pentium 4
- pourquoi Intel a echoué avec l'Atom malgré pratiquement 10 ans de dumping ultra-violent et partant d'une position monopolistique.
- pourquoi un x86 coute si cher et a produire et a acheter
- pourquoi la finesse de gravure sous les 22 nm n'apporte quasi rien ni en puissance ni en production thermique.
Le dernier elemement est certainement le plus remarquable car ingrédient clé de la recette magique d'Intel.
Passer de 22 a 14 nm c'est un saut technologique monstrueux et un des sports les plus maitrisé par Intel.
Pourtant, non seulement Intel a un taux de dechets superieur en 14nm a toutes ses precedentes gravures, une rentabilité en baisse si importante que les nouvelles usines de production ont ete annulé, mais pire que tout l'efficacité énergétique n'est pas meilleure qu'a 22nm!
La seule vraie avancée qui a permis une petite amélioration sur la consommation c'est le FINFet, ce qui n'a rien a voir ni avec la gravure ni avec l'architecture.
Pourtant on a une réduction de la taille, des espaces a franchir, des métaux a traverser,… de plus de 40%!
Si tu dois courir sur une distance 40% plus courte a la meme vitesse, non seulement tu vas arriver plus vite mais en depensant moins d'energie et moins fatigué! C'est du bon sens, sauf pour le x86!
Ça veut dire quoi alors si avec une diminution de 40% de la distance tu arrives dans les memes temps et aussi fatigué?
Ton poids a augmenté de 40%, ta puissance musculaire a diminué de 40%?
Et pourquoi Intel a donc autant triché sur le TDP, mis en place un systeme pour leurrer les bench qui fait passer celui de VW pour un jouet grossier!
@C1rc3@0rc
"Delenda Carthago"
Ben faut bien voir que le triomphe du x86 dans le PC puis dans le serveur c'est pas le triomphe de la technologie mais de la strategie commerciale monopolistique a gand renfort de pratiques de concurrence deloyale, de controles des producteurs et consommateurs sous un meta-systeme veritablement pervers et incontournable.
Et que la premiere victime technologique, après l'utilisateur final, c'est Intel et sa R&D.
Si l'hydre Wintel (Microsoft + Intel) a reussi a mettre le marché sous contrainte et captivité c'est pas avec les meilleures technologie existantes, plutôt avec les plus déficientes d'ailleurs quand on regarde Windows 3 ou 95 et les Pentium 3 et 4.
C'est surtout une demonstration magistrale qu'une economie financiere speculative est antagoniste de l'economie de marché et s'oppose au principe meme revendiqué de darwinisme en economie.
Faut se rappeller que Microsoft a toujours vendu a perte, pour ne pas dire a payer cher pour equiper le monde avec Windows et qu'Intel a fait de meme avec le x86. Faut bien comprendre que si Intel a englouti des milliards pendant 8 ans pour essayer d'imposer l'Atom dans le mobile ce n'est que la poursuite de sa stratégie pour prendre le marché du PC puis celui du serveur. Le client du PC a payé la politique de conquette du serveur, puis le client du serveur a payé la berezina de l'Atom, et maintenant c'est le datacenter qui paye pour maintenir le PC et developper l'IoT...
Maintenant ils vont faire de l'ARM, pour financer quoi? Le maintien du datacenter ou du PC?
@C1rc3@0rc
"Faut se rappeller que Microsoft a toujours vendu a perte, pour ne pas dire a payer cher pour equiper le monde avec Windows"
Quand on en est à mettre en avant de telle conneries on perd vraiment toute crédibilité.
Plonge toi dans les compte d'exploitation de MS depuis son IPO
C'est vraiment du délire là
"pourquoi le x86, modele CISC, survit uniquement grace a son moteur RISC depuis le Pentium 4"
C'est n'importe quoi. Le décodage d'instruction en micro-ops dans le x86, ça existe depuis "toujours" (au moins depuis le x86), et ce qui est fait en interne n'a aujourd'hui plus rien à voir avec du RISC.
"- pourquoi Intel a echoué avec l'Atom malgré pratiquement 10 ans de dumping ultra-violent et partant d'une position monopolistique."
Parce que quand tu as un acteur déjà bien installé, il est extrêmement difficile de le déloger sans avoir une avance technique très importante dessus. Surtout quand tes plus gros clients potentiels (genre Samsung) sont très intéressés par l'idée de faire leurs CPU eux-même.
Et bien sûr, il y a dix ans, Intel était à la ramasse par rapport à ARM sur la mobilité. Parce qu'il ne s'était jamais intéressé à ce marché. Mais il a petit a petit refait son retard, et sur la fin, il était largement à niveau. Compare les autonomies des tablettes Windows Atom et des tablettes Windows ARM, tu verras que c'était du même ordre...
Sur la fin, le seul handicap technique qu'avait Intel, c'était son retard sur les modems intégrés.
"- pourquoi un x86 coute si cher et a produire et a acheter"
Il ne coûte pas cher à produire. Il coûte cher à acheter parce qu'Intel profite de la quasi absence de concurrence pour s'en mettre plein les poches.
Je l'ai déjà dit plus haut, mais je le rappelle : une puce comme l'Apple A9, avec ces deux cœurs, c'est plus gros et donc plus cher à produire (le coût de production d'une puce dépend directement de sa surface) qu'un SoC Atom serveur à 4 cœurs vendu 200$. Avec 190$ de marge brute pour Intel...
"- pourquoi la finesse de gravure sous les 22 nm n'apporte quasi rien ni en puissance ni en production thermique."
Le gain d'efficacité énergétique en passant de Sandy à Ivy (quasiment juste un changement de finesse, avec des retouches mineures de la micro-architecture), c'était 20%. T'appelles ça quasi-rien ?
"Passer de 22 a 14 nm c'est un saut technologique monstrueux et un des sports les plus maitrisé par Intel.
Pourtant, non seulement Intel a un taux de dechets superieur en 14nm a toutes ses precedentes gravures, une rentabilité en baisse si importante que les nouvelles usines de production ont ete annulé, mais pire que tout l'efficacité énergétique n'est pas meilleure qu'a 22nm!"
Tu mélanges tout ! Intel a eu des difficultés pour passer à 14nm, oui. Mais il s'agit de difficultés sur le processus de gravure, difficultés qui n'ont donc strictement RIEN à voir avec l'architecture (à la limite, la micro-architecture, mais même là, pas trop...).
Ce n'est d'ailleurs pas le seul à s'être cassé méchamment cassé les dent sur un changement de finesse de gravure, et il y a eu de la casse aussi dans le monde ARM (on en parle du Snapdragon 810 ?)
"Et pourquoi Intel a donc autant triché sur le TDP, mis en place un systeme pour leurrer les bench qui fait passer celui de VW pour un jouet grossier!"
Dans ce domaine, c'est côté smartphone qu'on trouve les champions toute catégorie hein...
Là où Intel met en avant une fréquence de base garantie en toutes circonstances (si le refroidissement est conforme à ses préconisations bien sûr) et une fréquence turbo qui sera atteinte si les conditions le permettent, sans garantie, les fabricants de SoC ARM ne mettent en général en avant qu'une seule fréquence... qui est en fait l'équivalent de la fréquence turbo d'Intel, et en aucun cas une fréquence de fonctionnement garantie... Résultat, quand tu lances un bench une fois, ça dépote en moulinant à la fréquence maxi, mais dès que tu le lances plusieurs fois de suite, ça se met très vite à throttler... Y compris les CPU Apple, pourtant très efficaces : http://cdn.arstechnica.net/wp-content/uploads/2014/09/iPhone-6-charts.016.png
@SartMatt
Quand C1rc3@0rc évoquait une étape de plus sur les x86, il me semble qu'il parle de l'étape de conversion du code x86 vers le code natif de la micro-architecture réelle du CPU.
Il ne rentrait pas sur des considération de construction du pipeline, me semble-t-il
C'est un de ces point de fixation classique.
Ah oui, peut-être. Mais même dans ce cas, c'est faux aussi.
D'abord, parce que comme le nombre d'étages du pipeline, ça n'a pas d'influence directe sur les performances (ça en a par contre sur la complexité de la puce, donc sur sa consommation, mais ça va dans les deux sens : d'un côté tu complexifies le décodeur, de l'autre tu simplifies les unités de traitement...), seulement sur la durée de traitement d'une instruction.
Ensuite, parce que le principe du jeu d'instruction interne différent du jeu d'instruction externe, avec un traducteur, ça existe aussi sur des CPU ARM. Et notamment, encore une fois, sur ceux considérés comme les plus performants dans le domaine des smartphones : les CPU Apple. On le retrouve aussi sur certaines micro-architectures ARM clés en main (au moins depuis le Cortex A15, mais sans doute déjà avant, j'ai juste la flemme de chercher ^^).
C'est une étape quasi inévitable d'ailleurs si tu veux faire de l'out-of-order, parce que plus tu découpes en petites instructions, plus tu vas pouvoir optimiser le reorder pour maximiser l'utilisation des unités de calcul disponibles.
Et les CPU ARM avancés font également, comme les Intel, du "recollage" de certaines micro-ops pour reformer des macro-ops après le décodage.
En fait, au niveau micro-architecture, il n'y a pas tant de différence que ça aujourd'hui entre un CPU ARM et un CPU x86, on retrouve les mêmes concepts, la même organisation...
@SartMatt
Tu n'ai pas le premier à essayer de lui expliquer, mais quand la base du raisonnement est : "Intel c'est le mal" ce n'est pas simple de faire passer le message que les choses ne sont pas aussi caricaturale qu'il ne veut le penser ;-)
Il y des moments où @C1rc3@0rc me donne l'impression d'être resté bloqué sur les problématiques et des visions des années 90
@awk
Oui ca sert a rien.
Il est resté coincé sur les concepts des années 90, x86 c'est le mal...
Mais surtout, jamais aucune source citée, il faut le croire sur parole, donc même dans une discussion que tu appuies par des sources qui permettent de verifier tes dires, la seule réponse que tu obtiens c'est un pavé ou se mélangent vérité et absurdité. Il suffit de voir le pavé sur Switf dans les posts.
@Stardustxxx`
C1rc3@0rc, c'est vraiment un cas très particuliers.
Les connaissance académiques et les références sont les bonnes, il y a une vraie connaissance des sujets ... mais déjà elle semble effectivement être resté bloquée sur les problématiques et les visions en vogue dans les années 90, ce qui est étonnant.
Après ur ces fondations il part souvent dans le dogmatisme touchant parfois le grand n'importe quoi et a tendance à utiliser ses connaissances et son intelligence pour donner des atours rationnels à ses goût et dégoûts.
Ajoutes à ça un rapport au monde qui semble être issue du rigorisme calviniste ça donne un étrange mélange.
C'est vraiment un type qui me laisse dubitatif même s'il est intéressant et attachant.
Je dois avouer essayer de reconstituer le parcours qui peut être le sien, c'est assez intriguant comme personnage.
@Stardustxxx
"Mais surtout, jamais aucune source citée, il faut le croire sur parole"
ça cela ne me dérange pas plus que ça, il faut s'avoir accorder un peu de confiance quand on sent que la personnes sait de quoi elle parle sinon ça devient de la réthorique mécanique assez fatigante et stérile.
il faut savoir faire confiance en sa capacité à juger la valeur de son interlocuteur, de mon point de vue, elle se dessine quand même assez rapidement après quelques échanges.
@awk
Dans le cas d'opinions divergentes, il est toujours bien de citer ses sources. Personne n'a la connaissance infuse, il est toujours bien de vérifier que ce que l'on affirme est fondé.
Et comme il est si facile de poster m'importe quoi, pouvoir consulter les sources est toujours intéressant et permet de garder ses connaissances a jour.
Si quelqu'un me dit que j'ai tord, et me cites des articles pour pouvoir mieux m'informer, je vais aller lire ces articles pour me mettre a jour si ces sources sont fondés.
@Stardustxxx :
C'est sans doute un péché d'orgueil de ma part mais je fais confiance en ma capacité à juger la qualité de mon interlocuteur et la qualité de ce qu'il avance quitte à creuser un peu dans la discussion pour voir ce que le gars à dans le bide. ;-)
@SartMatt
D'ailleurs quand on regarde le modèle de programmation des ARM il n'est pas si RISC que cela et il s'éloigne assez nettement du strict sens du concept.
@SartMatt
Ce sont de foutaises que tu racontes.
Tu veux faire passer le cycle entier de traduction-compilation dynamique du x86 pour du traitement au niveau du micro-code. C'est faux.
Tes explications compliquées tentent juste de cacher un fait qui est pourtant simple a comprendre: le x86 doit faire 2 fois le traitement que fait un ARM et dois faire a chaque cycle les traitements que dois faire une fois pour toute le programmeur et son compilateur.
Les processeurs RISC comme les ARM necessitent que le traitement de traduction et optimisation du code se fasse au niveau du compilateur et cela une fois pour toute.
Le x86 c'est une machine virtuelle physique, qui fait de maniere dynamique la compilation a la volée, avant de d'envoyer le code au coeur RISC.
Apres y a un traitement similaire dans le core pour executer le microcode ce qui fait une redondance inutile dans le x86.
Tu peux prendre le probleme comme tu veux, dans tous les cas le systeme CISC implique une phase de traitement supplémentaire au niveau du processeur. En fait 2 parce que c'est en entrée et en sortie.
Alors c'est certain, pour le programmeur le travail est plus simple sur un x86 qu'un ARM et l'importance du traitement du code C(ou autre) vers x86 est tres relative.
Sur un ARM et un RISC en general, la qualité du programme va dependre des competences du developpeur et de la qualité de son compilateur.
C'est pourtant simple a comprendre. Si tu organise tes documents a l'avance et au fur et a mesure qu'il arrivent, tu es plus efficace, rapide et depenses moins d'energie (ARM) que si tu dois fouiller dans un tas de feuilles eparpillées a chaque fois que tu dois trouver dans lurgence un document (x86).
Pages