L'architecture ARM ne peut encore remplacer l'x86, regrette Linus Torvalds

Florian Innocente |

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.

Archimedes A410, crédit nightfallcrew — Cliquer pour agrandir

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…

avatar SartMatt | 

"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. [...] 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)."

Oui oui, bien sûr, un CPU ARM exécute tout exactement dans l'ordre donné par le compilo. La bonne blague... Tous les processeurs ARM performants découpent eux aussi les instructions en micro-ops, parfois font de la fusion de micro-ops, et finalement les réorganisent pour les traiter dans le désordre (tous les Cortex haut de gamme sont out-of-order depuis le A9, toutes les micro-architectures ARM d'Apple et de Qualcomm également...).

Désolé de te décevoir, mais la réalité, c'est que les processeurs modernes et performants, en interne, ils ne sont ni RISC ni CISC. Ils sont VLIW. Et on a dans tous les cas une étape de traduction pour passer des instructions externes RISC ou CISC aux instructions internes VLIW.

Va lire un peu les docs techniques d'ARM ou les articles très détaillés que font les sites comme Anandtech au sujet des différentes micro-architectures. Tu risques d'avoir quelques surprises...

En fait, le seul CPU moderne qui s'approche un peu de ce que tu décris, avec une exécution brute du code machine tel qu'il est sorti par le compilateur, c'est l'Itanium. Là effectivement, c'est même le compilo qui décide de quels instructions doivent s'exécuter en parallèle sur le CPU. Parce que lui expose directement une ISA assez similaire à du VLIW.

avatar awk | 

@SartMatt

Merci de m'avoir remis en mémoire l'architecture EPIC qui en était un peu sorti.

Effectivement c'est sans doute la dernière architecture qui reposait sur un non réordonacement à l'exécution reportant tout le boulot sur le compilateur.

avatar awk | 

@C1rc3@0rc

"e 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."

Tu as déjà développé en Objective-C ?

A te lire on peut se poser la question

Après j'apprécie beaucoup bien des apports de Swift là n'est pas la question.

Mais tu pousse beaucoup la caricature radicale quand même.

avatar C1rc3@0rc | 

Alors oui je connais et j'ai travaillé en assembler, Pascal, Object Pascal, Modula, Oberon, ADA, Eiffel, Lisp, Prolog, DyLan, Hypetalk, C, C++, Objective-C, Java, CaML, Haskell, Python, R, Javascript, different shell évidement, et des langages comme LaTeX, HTML. J'ai développé des compilateurs pour plusieurs notamment des couches objets pour les procéduraux .

je peux donc te parler autant du point de vu du developpeur applicatif que de celui qui realise le compilateur et meme la programmation directe du matériel (notamment dans l'embarqué). Le C c'est un super assembleur de haut niveau. Si tu sais ce que tu fais precisement, que tu maitrise le materiel, C te permet de gagner beaucoup de temps et de faire des choses trop complexes pour de l'assembleur. Mais c'est un mauvais langage applicatif d'autant plus que l'application est de haut niveau et abstraite.

Le fait est que le C, meme dans une version aussi verrouillée et compliquée que le C++ ( qui est avant tout une tentative de sécurisation du C du modele Ada, bien avant l'ajout de la couche objet) reste du C avec ses defauts et l'impossibilité de vérifier la validité du code face au bidouilles et erreurs possibles du programmeur.
L'Objective-C c'est la philosophie laxiste du C a 100% avec un couche objet de Smalltalk et l'idée du late-binding des langages de haut niveau, qui fait que le code est imprevisible par nature (mathematiquement). Tu peux tourner le truc dans tous les sens, impossible de securiser statiquement, et donc de prevoir ce qui va se passer en memoire.

Objective-C c'est une tentative d'avoir un Smalltalk rapide avec le cout et les contraintes minimalistes. Tout programme C est un programme Objective-C valide. L'aberration a ete la gestion de la memoire qui necessite un systeme automatique complexe et qui a ete realisé a minima avec une philosophie C. Et a l'origine Objective C etait construit sur des Lisp...

avatar awk | 

@C1rc3@0rc :
Tout ce que tu avances est plutôt juste mais cela ne change rien à l'étrange impression un rien de caricature que me laisse ta contribution sur Swift.

Il y a toujours chez toi une outrance qui fait que même quand on est plutôt d'accord avec toi il manque quelques chose pour l'être vraiment.

avatar ovea | 

@fiatlux :
Faire tourner en émulation x86

Surtout pas !

Le but étant, il faut encore le rappeler de se passer des programmes avec de douteuses optimisations, boudeuses face à la programmation fonctionnelle.
Des programmes en émulation x86 qui recherche la question à la réponse existentielle du chauffage autour d'un PC.
Juste parce que ça ne sert à rien, ces vieux programmes qui font des boucles d'attente comme on allume de vielles ampoules à incandescence, au lieu d'être à l'écoute de l'environnement d'exécution.

avatar JLG47_old | 

@Nicolapps :
Apple ne peut pas faire l'impasse sur la base logicielle existante.
Il y aura nécessairement une passerelle ou un viaduc pour assurer la transition (10 ans pour Rosetta)

avatar awk | 

@JLG01 :
Très loin d'être certain, la donne n'est plus celle de la transition PowerPC/x86

avatar oomu | 

@Nicolapps

oui, les logiciels devront être recompilés et surtout Re-testés, re-validés, re-certifiés par le service qualité, etc etc (c'est ce qui sera le plus long en réalité) et aussi c'est à CE MOMENT (et pas avant) qu'on réalisera s'il y a des régressions et bugs majeurs)

Si une app os x a été conçue en se conformant uniquement aux apis de Cocoa et ce que l'App store permet, forcément Apple sera en mesure de proposer l'équivalent en ARM.
Mais n'oubliez pas qu'il y a malgré tout 40 ans d'histoires de code Mac derrière, même si Apple avec Os X puis le passage à Cocoa 64b a tenté de gommer toutes les traces d'anciennes bibliothèques de développement pour avoir tout portable.

-
il est peu réaliste d'imaginer un émulateur de code intel sur arm : ça sera trop couteux pour être intéressant.

Lors du passage au mac intel, Rosetta avait des performances à peu près acceptable parce que IBM avait laissé s'accumuler un tel retard sur le PowerPC que les processeurs Intel du moment avec un peu de rab de puissance pour accuser le coup. Mais c'était pas idéal. Avec ARM ce n'est PAS le cas. Il n'y a pas de processeur ARM qui dépasse ceux d'Intel.

avatar Moonwalker | 

Et encore, Rosetta donnait l'équivalent d'un G4, pas d'un G5.

avatar awk | 

@oomu

"Il n'y a pas de processeur ARM qui dépasse ceux d'Intel."

Est-ce là un pb ?

L'objectif d'Apple ne semblerait pas de remplacer les CPU x86 pour tous les types d'usages mais pour ceux très majoritaire où la puissance offerte par les CPU ARM est en ligne avec les besoins.

Par exemple un MacBook à architecture ARM ne semble pas improbable.

L'enjeux pour Apple est de retrouver des degrés de liberté différentiant sur son offre qu'Intel ne lui offre plus.

avatar C1rc3@0rc | 

@oomu

MacOS c'est surtout NeXTStep au niveau de l'architecture.

«il est peu réaliste d'imaginer un émulateur de code intel sur arm : ça sera trop couteux pour être intéressant.»

Lors du passage a Intel il y a eu une regression de puissance du core par rapport au G5. La première machine est passée d'un G5 64 bit a 2Ghz a un Intel Core duo 32bits a 1.8Ghz . Et on parle meme pas du Mac Mini avec son core solo...
Et pourtant cela n'a pas arreté Apple et heureusement qu'il y avait 2 core pour encaisser la regression et faire de l'emulation.
Ce qui a permis a Intel de prendre le marché Mac c'est 2 choses: l'indigence de Motorola et le fait que le G5 etait un processeur desktop qui chauffait trop pour rentrer dans un portable. Intel ramenait des processeurs multicore moins puissants mais qui chauffaient moins et qui coutaient moins chers...

Aujourd'hui on est dans une situation ou les processeurs equipant les Mac ont des alternatives ARM au moins equivalentes en puissance par core et vu le faible cout des core ARM on peut en facilement avoir de l'octocore pour le prix, voire moins, d'un dualcore Intel... donc l'emultation c'est vraiment pas un probleme technique. Et l'émulation est justement un type de traitement qui profite du multicore!

Ceux qui ont peur du passage a ARM ce sont surtout ceux qui achetent un Mac pour faire tourner des soft PC, parce que la effectivement ça va etre compliqué, pas a cause de la puissance mais de l'interet. Serait ttres ettonant que Parallel investisse pour fournir un aussi petit marché que celui du Mac. Aujourd'hui c'est rentable parce que la virtualisation c'est le proc qui la prend massivement en charge mais avec de l'ARM ça demanderait beucoup de boulot, et les acheteurs de Mac qui font tourner du soft PC c'est vraiment pas beaucoup de monde.

L'interet d'Apple c'est d'assurer ses marges et de les gonfler. Plutot que payer tres cher des x86 Apple peut mettre des ARM avant tout destinés aux devices = benefices!

avatar Moonwalker | 

MacOS c'est surtout NeXTStep au niveau de l'architecture.

C'est un peu de la légende urbaine, savamment entretenue pas Jobs en son temps. En tout cas, c'est un gros raccourci.

Mac OS X c'est un peu de OpenStep (l'API Cocoa), un peu de Copland (API Carbon), un peu de BSD, et un peu de MacOS (QuickTime).

Le noyau et ses dépendances sont réécrits. Le noyau de NeXTStep était Mach (un micro kernel) associé à une couche de BSD 3. Le noyau d'OS X est XNU (un noyau hybride), basé sur Mach 3 et FreeBSD. C'est une refonte complète.

L'architecture générale renvoyait autant aux idées de Copland qu'à celles de NeXTStep et l'interface doit beaucoup à MacOS. Par exemple, le bureau est une notion absente de NeXTStep.

La promesse de Steve Jobs en 1998, porter OpenStep sur les machines Apple n'a jamais été tenue, ou plutôt elle n'a pas survécue au projet Rapsody/Mac OS X Server.

Il n'y a pas tant de continuité entre NeXTStep et Mac OS X. Ce dernier n'en est qu'une reprise partielle, même si certains concepts en ont été repris, et pas des moindres.

avatar awk | 

@Moonwalker :
Yep

Il y a à la fois beaucoup et très peu d'héritage NeXT dans macOS

Le beaucoup tenant plus d'une vision générale et le très peu de la réalité du code

avatar JLG47_old | 

@Nicolapps :
Une sorte de retour aux sources, enfin avant le passage sous Intel, avec les PowerPC dont le seul vrai défaut est d'avoir cesse d'évoluer.

avatar françois bayrou | 

Article intéressant
il me donne l'impression que le bon titre serait plutôt "Apple peut permettre à l'architecture ARM de remplacer l'x86"

tremble Intel, tremble

avatar robrob | 

@francois bayrou
Si Apple decide de tout passer sur ARM ils peuvent le faire parce qu'ils controlent entierement l'"ecosysteme" a creer autour de l'architecture et n'ont pas de besoin de portabilite.
Ca ne veut pas dire qu'ils vont standardiser l'ecosysteme qu'ils vont creer.

Linux a besoin de portabilite et se retrouve avec un probleme bien different. Du coup ce que dit Linus n'a pas grand chose a voir avec ce qu'Apple peut faire avec ARM.

avatar awk | 

@françois bayrou :
Effectivement ta conclusion me semble plus juste que le titre de la news

On peut entre les lignes lire : ce qui manque à ARM pour sauter le pas c'est la puissance d'un acteur majeur voulant faire la transition

avatar béber1 | 

awk
On peut entre les lignes lire : ce qui manque à ARM pour sauter le pas c'est la puissance d'un acteur majeur voulant faire la transition"

c'est ce que j'ai lu aussi

avatar Lonesome Boy | 

Si Linus le dit, c'est que c'est sûrement faux vu le background de ce type...

avatar awk | 

@Lonesome Boy :
Linus Torvalds n'est effectivement pas particulièrement réputé pour ses talents de visionnaire

avatar oomu | 

?

avatar awk | 

@oomu

Les visions de Linus Torvalds sont très souvent questionables, pour le moins.

avatar Un Type Vrai | 

La preuve, le type choisi des architectures qui se plantent a chaque fois... La guigne.

avatar TotOOntHeMooN | 

Linus qui en oublie le cross-développement et l'escence même de Linux.

avatar awk | 

@TotOOntHeMooN :
Pas que de GNU/Linux :-)

Sa fixation sur le cross-dev est effectivement assez étrange

avatar oomu | 

non. le soucis est le retard de ARM.

Si vous cherchez dans tout ce qui est bibliothèque de programmation, calcul haute-performance, outil tel que IDE, debuggage, etc. Vous avez pratiquement rien sur ARM.

Effectivement vous avez des toolchain comme ceux de GNU...

Mais un example frappant : il n'y a pas pour l'heure de XCODE "arm".

On programme les appareils ios (arm) avec des Mac (du x86)

et ce n'est pas un hasard encore une fois.

-
ensuite se pose la question des fonctionnalités du processeurs : instructions de calculs vectoriels, virtualisation, hyper-threading et j'en passe.

On a pas pour l'heure de processeur ARM mis au même niveau qu'un processeur tel un core i7 ou Xeon.

avatar awk | 

@oomu

En quoi le cross développement est-il un frein ?

J'ai du mal à voir.

L'ensemble du très porteur marché des terminaux mobile c'est développer sur ce mode de développement sans grand écueils il me semble.

Des milliers de logiciels pour consoles de jeux sont issue de cette approche

Et je ne parle pas de tout ce qui est de l'ordre de l'informatique embarquée

Je ne vois vraiment pas en quoi le cross-developement est un handicap insurmontable aujourd'hui ?

avatar byte_order | 

La cross-compilation, non.
Le cross-développement, si.

Traquer des bugs dans du code asynchrone en mode "remote", c'est vraiment pas la joie. Déjà que sur la cible même c'est pas facile, mais là... gloups.

J'ai souvenir d'un bug dans la pile USB d'un firmware alpha pour LiveBox 2 qui m'a bien pourri une semaine...

Et les interfaces type JTAG sont nettement plus pauvres que les capacités d'introspection natives d'un CPU de nos jours.

avatar awk | 

@byte_order

"Le cross-développement, si."

Tu me sembles extrapoler largement de quelques problématiques que tu rencontres et qui ne me semble pas avoir prise sur un éventuel macOS ARM.

Le cross-development est aujourd'hui une norme sur bien des industries de masse :
- smartphone et mobile
- console de jeux

et les outils permettant d'y faire face sont plus que mature.

Un devellopement à partir d'un macOS x86 ciblant un macOS ARM ne semble pas tenir du défis d'autant que la cible est un vrai ordinateur complet faisant tourner le même OS sur lequel peuvent tourner les même outils de debug/monitoring/profiling ..

Je continus à considérer que ce n'est pas la un frein à une potentielle transition d'une part de l'offre Mac sur ARM.

avatar ovea | 

@byte_order :
Cross-dev

Justement, si la même application iOS se télécharge sur iPhone, iPad Pencil, aTV … et demain iBouc, on'Ne pourra plus prétendre dépendre d'un paradigme de devdebugage, alors que le développement est devenu multi-cibles.
Reste l'abstraction de la mémoire d'exécution repartie à définir par Apple et l'exécution dans la LLVM d'OpenMP permettra de distribuer la bonne part du gâteau au bon appareil après le coup de fourchette.

avatar oomu | 

@awk

le point de Linus c'est qu'il n'y a pas, pour l'heure, de quoi REMPLACER notre ordinateur de Travail (bureau, avec Eclipse, Xcode, Visual Studio, et les 1 milliards de bibliothèques cobol, fortran, C, C++, C#, etc) sous x86/ia64 par subitement un ordinateur sous ARM.

Effectivement, on en est ENCORE à utiliser des machines sous intel (et vaguement amd) pour pondre du code pour les "Autres".

Mieux encore: pourquoi passer à des ordinateurs de bureau en ARM ? Le seul gain concret qu'on peut imaginer actuellement c'est + de contrôle sur le design pour Apple. Apple pourrait maitriser son planning de sortie (comme le A10). Mais pour nous ?

-
je n'ai pas dit que le cross-developpement est un frein. Je dis que le fait qu'on se contente de cross-developper démontre qu'il n'y a pas de demande pour des ordinateurs de travail sur ARM

et de toute façon, là tout de suite en octobre 2016 c'est plus que prématuré.

Car comme le dit Linus : y a po l'ecosystèmeuh (la myriade de codes, bibliothèques, outils, logiciels académiques, progiciels, et j'en passe: là où y a de l'Argent).

Et non, Angry Bird, 500 millions d'applications jetables sur android et 16 logiciels de productions sur ios ne sont pas un écosystème à la taille de Windows/Linux/intel. Même pas comparable au Mac.

-
Bien sur, Apple pourrait virer les mac, les remplacer par des MacArm et du jour au lendemain macOs serait prêt à exécuter les 160 clients twitter de l'App Store, les 2000 logiciels de retouche yeux rouges et bien entendu les applications Facebook.

mais au delà ?

(j'adore ProCreate sur ios, les logiciels d'omnigroup et l'ipad oui est productif. Mais là on compare à ce qui se fait sur INTEL, de tout ce qui existe dans le Cosmos de Windows, la Galaxie Linux et le Système Solaire Mac).

Je réactualiserai mon propos en 2017, 2018, 2019... ou si Apple annonce du jour au lendemain "ha oui au fait, on a porté Xcode, Logic, tout intel fortran et au passage LaTex/Miktex, lol !"

avatar awk | 

@oomu :
Qui parles de remplacer totalement se qu'offrent les PC ?

L'enjeu est l'existence d'un segment de machine macOS sous ARM pour un nombre d'usage certes limité mais couvrant la plus grande part des usages les plus courants.

Cela nous mène bien loin du basculement de tout sur ARM

avatar nicolas | 

Il y a Swift Playground :-)

avatar awk | 

Je ne partage pas l’analyse que vous faites de propos de Linus Torvalds qui pour moi relève de la surinterprétation. Il met en avant des freins à l’expansion de l’architecture ARM met ne pointe en fait aucune réelle limitation d’ordre technique.

Je ne vois rien dans ses propos qui serait de nature à invalider l’hypothèse d’une adoption par Apple pour une part des Mac à plus où moins long terme.

avatar oomu | 

il est très clair que pour lui le soucis est le manque d'un ecosystème viable autour de ARM.

et non pas simplement technique.

Si Apple construit l'écosystème (comprendre les outils de développement et tout le toutim AUTOUR) alors bien entendu, la technique ne sera pas un frein.

Mais pour l'heure, on ne voit personne le faire et son observation sur Raspberry Pi est juste.

Patience.

avatar awk | 

@oomu

Nous avons la même analyse du propos, mais je ne vois pas la pertinence de son emphase sur le cross-dev.

En quoi est-ce un frein ?

avatar oomu | 

le cross-dev n'est pas un frein.

C'est l'une des constatations que tout va bien, on a pas d'urgence à avoir des Ordinateurs de Bureau sous arm. vu qu'on a le cross-dev.

avatar awk | 

@oomu

Etrange logique dont les ressort m'échappe ?

Les raisons pouvant pousser Apple à adopter des CPU ARM sur certains de ses Mac sot très loin d'être avant tout de nature technique, l'enjeu est principalement d'ordre de la stratégie commerciale, cela semble assez claire.

avatar r e m y | 

@dark Mac
Il n'empêche qu'il est souhaitable qu'Apple développe un traducteur similaire à Rosetta, le temps que les applications soient mises à jour (et accessoirement, pour éviter de devoir racheter toutes ses applications dont la mise à jour risque d'être payante)

Mais Apple a deja géré 2 transitions (des puces 68k aux PowerPC puis aux puces Intel) de façon tres transparentes pour l'utilisateur. Il n'y a pas de raisons que ca se passe différemment si ils décident de passer sur des processeurs ARM.

avatar heret | 

Ben si !
Aux époques de ces 2 transitions, les gains de performance d'une génération de processeur à l'autre étaient patents. Ce n'est plus le cas aujourd'hui. Et en plus les performances des processeurs ARM sont en dessous de celle des processeurs Intel. Alors, faire de l'émulation Intel sur ARM, ça ne va pas se faire dans la transparence.

avatar awk | 

@heret

L'enjeu majeur de l'époque n'est plus du tout le gain de performance.

La grande majorité des usages informatique se contente de ce qu'offre les CPU d'entrée de gamme.

Un MacBook répond aujourd'hui à la très grandes majorité des usages en terme de puissance.

L'enjeu pour Apple serait de retrouver des degrés de liberté pour différentier son offre qu'elle ne peut avoir en restant sur une architecture Intel.

La donne n'est pas comparable avec celle qui conduisit au changement d'architectures précédents ;-)

avatar oomu | 

l'enjeu majeure est la latence de nos jours (que ça réagisse vite)

Mais donc, on sait déjà qu'un processeur ARM de bureau ne sera pas assez puissant pour émuler du intel sans que ça soit atrocement pénible pour l'utilisateur.

avatar awk | 

@oomu

"Mais donc, on sait déjà qu'un processeur ARM de bureau ne sera pas assez puissant pour émuler du intel sans que ça soit atrocement pénible pour l'utilisateur."

Je ne crois effectivement pas une seconde à une émulation logiciel accompagnant cette possible transition et je n'en vois même pas la nécessité.

avatar oomu | 

les processeurs intel , les core, quand Apple a migré, surclassaient les powerpc G5 qu'Ibm avait laissé vieillir. Et malgré ça, Rosetta pouvait être atrocement lent.

Peu crédible d'émuler suffisamment rapidement un core i5/i7 avec du ARM.

avatar awk | 

@oomu

D'autant que la nécessité d'émulation semble bien moins forte aujourd'hui qu'hier.

La base installée logiciel moyenne et le fruit d'une poignée d'acteurs, la distribution des logiciels est dématérialisée, bien des logiciels largement diffusé ont migré sur un mode de vente par abonnement ...

Si les deux architectures cohabitent, l'enjeu pour que l'offre sur de l'entré de gamme soit pertinente se réduit pour Apple à convaincre une poignée d'éditeur majeurs d'effectuer le portage et de donner les moyens de le rendre le plus transparent possible.

Il est d'ailleurs intéressant de noter qu'une bonne part de ces éditeurs ont déjà porté des variantes de leurs logiciels phare sous iOS

avatar oomu | 

je ne suis pas convaincu.

La plupart des cas macos/ios sont anecdotiques.

Parlez moi de 3DS Max, de Solidwords, de Autocad, de Adobe Creative CLoud DE LA TETE AU PIED, de Final Cut X, de Eclipse, de J2EE, de CIEL (!), etc.

S'il s'agit juste de faire un mac facebook/angry bird/correction yeux rouges (qui est un usage respectable et populaire), oui actuellement Apple pourrait basculer à ARM et une grande part des développeurs habitués à l'App Store ne verrait presque rien.

Mais j'insiste: si on fait ça en 2016 là tout de suite, vous allez hurler à la mort et ça ne sera pas un mac.

trop prématuré pour l'heure.

avatar awk | 

@oomu

Je suis surpris que tu n'es pas une vision plus claire de se que sont les usages d'une trés grande part des mac vendus aujourd'hui.

Les usages que tu évoques sont soit sous Wintel soit très marginaux en terme de PDM pour Apple

avatar ovea | 

@oomu :
« 3DS Max, de Solidwords, de Autocad, de Adobe Creative CLoud DE LA TETE AU PIED, de Final Cut X, de Eclipse, de J2EE, de CIEL (!), etc.»

Tout ça pour la baraque à côté de celle à l'épitaphe ” Les Mirages ” !

Des besoins de la carte de circuit imprimé multicouches à la gestion d'une entreprise et de tous ses salariées ainsi qu'aux règlements internationaux qui régissent les rapports administratifs … ?

L'ARM et peut-être plus ce que pourrait en faire Apple, forte de sa position de moteur de la post-évolution IBM-Intel-Microsoft, en sortant de cette croissance et de ces infrastructures, pourrait prévoir de ce lancer dans l'ordinateur personnel … dans la mesure ou c'est ce qu'elle a toujours vendu.

Un ordinateur personnel Apple.

Dans la main,
dans les bras,
relai pour projeter en grand,
prise pour à la maison les commander tous … les robots domestiques,
dans le creux de l'oreille,
presque au bout des doigts.

avatar oomu | 

pas convaincu.

trop geeks, trop complexes que tout ça.

sur la domotique, Apple avance lentement avec prudence, car il y a peu de raison que le public adhère à tout un fatras de bidule wifi IP buggués jusqu'à la moelle à maintenir régulièrement et prier que l'interconnexion en réseau mesh ne va pas dégénérer.

pour l'heure, le "iot" (ou domotique) reste un marché en attente.

-
pour vendre un ordi personnel, encore faut il des usages.

Sorti de l'informatique professionnelle et du jeux vidéo, on voit bien que pour plus en plus de gens, flagrant avec la jeunesse et les pays encore(!) en développement, qu'un smartphone de grande taille peut être le SEUL ordinateur qu'ils utiliseront.

Pages

CONNEXION UTILISATEUR