Mac ARM: Apple pourrait attendre encore un an ou deux, Réactions à la publication du 16/01/2015

[Lionel]

A plusieurs reprises nous vous avons rapporté de source très fiables qu'Apple avait dans ses cartons des prototypes totalement fonctionnels de Mac dotés de processeurs ARM.
Un célèbre analyste appelé Ming-Chi Kuo y croit. Mais pour lui, et nous sommes d'accord, Apple n'a pas l'intention de sortir ces machines dans un avenir proche. La société pourrait attendre au moins un an ou deux pour se lancer et prendre un des plus gros paris de son histoire récente.

Toujours selon ses informations, Apple aurait besoin de ce temps pour que ses puces ARM soient capables de concurrencer un processeur Core i3 ou un Atom. Cela permettrait à la société de proposer toute une entrée de gamme ARM, le reste devant continuer à tourner sur des processeurs Intel.

Cela introduit l'idée qu'Apple puisse avoir deux gammes de Mac avec deux architectures radicalement différentes. Ce serait difficile à gérer et même Microsoft qui avait deux modèles de tablettes Surface, une ARM et une x86 a fini par jeter l'éponge sur le premier modèle, se focalisant sur le second.
En effet, on aurait alors des Mac pouvant faire tourner certains logiciels, chose dont les autres modèles ne seront pas capables, un vrai casse-tête même au niveau commercial. Certes, certains imagineront à nouveau un miracle Rosetta mais nous vous rappelons qu'Apple avait réussi ce pari de l'émulation en remplaçant dans tous ses modèles un processeur G4 ou G5 par deux coeurs x86 déjà plus puissants individuellement. Or, il serait aujourd'hui certes possible de proposer un processeur ARM doté de 8 ou 16 cœurs puissants, mais il aurait alors une consommation supérieure à son pendant chez Intel, ce qui réduirait de manière totale son intérêt.
Lien vers le billet original

[iAPX]

Apple a déja eu deux gammes avec deux architectures, voire trois architectures différentes au niveau applicatif, et ça ne pose que peu de problèmes sur les logiciels grand-public (sans code natif)...

C'est peut-être l'occasion pour Apple de rebondir coté technologies et de se différencier des assembleurs de PC, en fait des cabinets de designs (si tant est qu'un parallélépipède rectangle puisse être qualifié de tel), qui font concevoir et fabriquer ailleurs.

[r@net54]

L'analyste en question évoque le passage dans les deux ans, donc entre aujourd'hui et 2017…

La question ne se pose pas en terme de puissance et l'émulation est une considération archaïque: ce qui tourne sur un iPad air 2 aujourd'hui tourne en ARM et donc la seule différence sera l'interface, celle du Mac étant adaptee a la souris+clavier!

Nul besoin d'émulation car les applications seront natives, et la transition se résumera a une case a cocher dans xCode dans le meilleur des cas et a une adaptation de l'interface dans le pire des cas. Rappelons aussi que MacOS n'est pas le premier a passer a ARM, Microsoft l'a fait (même si des considération marketing n'ont pas poussées a la réussite commerciale) et cela fait depuis très longtemps que les Unix, Linux en tête et Android fonctionnent sur ARM et x86… sans que l'utilisateur s'en rendent compte.

L'emulation lors des passage du 68k au PowerPC et du PowerPC a Intel était nécessaire du fait que le marche Mac était restreint, que les developpeurs codaient pour un microprocesseur et qu'il n'y avait que le Mac, ses 5% de PDM et c'est tout.

Aujourd'hui Apple est un leader avec des milliers de développeurs qui programment depuis des années pour iOS, donc ARM.
iOS c'est a 95% MacOS X, la différence majeure étant les API graphiques (UI) et les API de téléphonie (et encore avec Yosemite ça change). Donc aujourd'hui le développeur code pour une API, par pour un jeu d'instructions (enfin c'est moins vrai pour le GPGPU mais ça tend a se normaliser aussi)
On a vu d'ailleurs ces dernières années des developpeurs iOS passer leur logiciels sur Mac OS X, et cela, de leurs commentaires, est rapide, même si la réflexion lie au multifenetrage et a la dimension de l'écran peut offrir des opportunités de développement qui nécessitent une petite mise a plat de l'interface.

Deja les gros éditeurs ont portes des pans entiers de leurs softs sur iOS...
Donc l'émulation est une fausse considération.

Niveau de la puissance, c'est pareil. On le voit avec l'iPad Air, dont le processeur est surdimensionne, il fait aussi bien qu'un MBA de 2011 et au niveau graphique il fait mieux.

La date de passage sera donc plus marketing et stratégique et économique. Intel aujourd'hui, on le voit avec l'atom, fait des efforts considérables pour résister a l'érosion du PC, tente de rattraper désespérément son absence du mobile, et pour cela encaisse des pertes massives avec ses processeurs mobiles qui sont offerts bradés a des tarifs qui ne generent pas de revenus (et probablement ils sont vendus a perte si on compte les subventions et supports d'Intel).

Il est clair qu'Intel voudra garder Apple comme client le plus longtemps possible et va faire des efforts tarifaires considérables pour maintenir ses core ix dans les Mac.
Et de l'autre cote Apple doit pouvoir compter sur ses fournisseurs de SoC de manière fiables pour lui fournir ses processeurs, et on le voit pour l'instant, c'est la guerre entre TSMC et Samsung, avec GF qui arrivera d'ici quelques mois, et Intel qui va fatalement produire de l'ARM.

Bref au niveau des considérations techniques, les Mac ARM pourraient arriver a partir de cet été. Apres ce sont donc les considérations stratégiques et marketing qui vont fixer la date.

Mais, encore une fois, si le passage du 68k au Power PC a été marquant, celui du PowerPC a Intel, hormis les problème idéologiques, a été bien moins important. Le passage du x86 a l'ARM sera totalement anecdotique et nombre d'utilisateurs ne s'en rendront meme pas compte.

De toute façon le mouvement du passage du PC a ARM est en route. On voit ces deux derniers années la multiplication des mini-PC ARM Android/linux, le développement des serveurs ARM, la montée en puissance des appareils mobiles qui concurrence les PC… Bref pour une fois Apple ne sera pas a l'avant garde mais ne fera que suivre la tendance inéluctable en cours...

[zero]

Nul besoin d'émulation car les applications seront natives, et la transition se résumera a une case a cocher dans xCode dans le meilleur des cas et a une adaptation de l'interface dans le pire des cas.

Ben voyons, Apple sort un Mac ARM et hop, c'est magique, toutes les applis deviennent natives.
Faut arrêter la moquette !

Ce message a été modifié par zero - 16 Jan 2015, 00:52.

[MacMobile]

Xcode n'utilise plus le GCC mais le LLVM (Low Level Virtual Machine)
Est-ce qu'une transition a ARM passerait par cette VM ???

[jipeca]

J'ai l'impression que j'en ai pour des années avec Snow...

[El Bacho]

Xcode n'utilise plus le GCC mais le LLVM (Low Level Virtual Machine)
Est-ce qu'une transition a ARM passerait par cette VM ???

Non, ça reste en fait le nom d'un simple compilateur, qui est simplement mieux optimisé pour Objective C (et sans doute Swift) que ne l'est le GCC. En fait, LLVM n'est plus un sigle et les quatre lettres ne se réfèrent plus forcément à une machine virtuelle, vu que le projet a très vite élargi sa mission par rapport à la vocation du début (j'avais d'abord écrit "initiale" mais c'était ambigu).

Je rappelle que les applications disponibles sur OS X (enfin sauf celles en Java) ou iOS sont compilées, à la différence d'Android, qui fonctionne avec une machine virtuelle et une compilation JIT. Là, la question de la transition d'architecture ne se pose plus du tout.

Ce message a été modifié par El Bacho - 16 Jan 2015, 01:15.

[Kierkegaard]

J'ai l'impression que j'en ai pour des années avec Snow...

T'es pas le seul, je t'assure. Là où je vis, il fait une Snow tempête. ^^

[Alizés]

À l'ARM et son retard de calendrier, comme à l'alcool qui tue lentement, une seule réponse :
-"On s'en fout, car on n'est pas pressés !"

Ce message a été modifié par Alizés - 16 Jan 2015, 06:40.

[fuby]

Apple a déja eu deux gammes avec deux architectures, voire trois architectures différentes au niveau applicatif, et ça ne pose que peu de problèmes sur les logiciels grand-public (sans code natif)...

C'est tout l'opposé ! Apple ne fournir des outils que pour faire du code natif ! c'est d'ailleurs pour cela qu'ils demandent l'architecture cible DES LE DEBUT D'UN PROJET Xcode.
Et c'est bien la le problème, le code natif DEMANDE de l'emulation, non pas comme sur android, qui utilise Java et de la "compilation" a la volée qui simplement transforme le bytecode java en code natif du CPU de la machine (c'est pour cela que android exist sur atom simplement)



A l'heure actuelle, tout est possible, la question est principalement : pourquoi le faire !

Si c'est juste pour le fun technique : c'est pas un bonne raison pour Apple
Si c'est pour avoir plusieurs architectures : ils en on deja plusieurs, ARM et x86
Si c'est pour du pognon : c'est un bonne raison pour Apple !


Il faut quant meme comparer ce qui est comparable : les CPU ARM Apple sont comparable a des atom, voire des core i3 pas trop rapides, et Apple n'utilise ni l'atom, ni le core i3.
La seule raison pour Apple de passer a de l'ARM c'est pour faire des marges plus grosses, mais sur quel type de produit ? les portable bas de gamme genre netbook : Apple ne fera jamais de netbook, c'est trop "bas peuple"

Ensuite, vouloir passer sur ARM : pourquoi penser a Mac OS X, et pas simplement iOS avec un portable, tactile : en somme un "ipad pro" avec un clavier a du sens pour attaquer le marche de l'entreprise : gerer les portables comme les tablettes et les telephones portables, avoir la possibilité du tactile, avec l'avantage du multi device, et enfin, des applications (natives) des le debut, la seule difference pouvant etre la RAM (plus grosse) et les connecteurs (USB ?, ou plutôt lightning ;-)) enfin, plus de problème de development de l'architecture car elle propose la meme unique, et l'on un un gamme mobile/portal unique, et surtout des marges bien plus grande car on a la R&D, et on paye uniquement la fabrication du CPU.

Non, ça reste en fait le nom d'un simple compilateur, qui est simplement mieux optimisé pour Objective C (et sans doute Swift) que ne l'est le GCC. En fait, LLVM n'est plus un sigle et les quatre lettres ne se réfèrent plus forcément à une machine virtuelle, vu que le projet a très vite élargi sa mission par rapport à la vocation du début (j'avais d'abord écrit "initiale" mais c'était ambigu).

Je rappelle que les applications disponibles sur OS X (enfin sauf celles en Java) ou iOS sont compilées, à la différence d'Android, qui fonctionne avec une machine virtuelle et une compilation JIT. Là, la question de la transition d'architecture ne se pose plus du tout.

clair, et c'est pour cela qu'en meme temps, cela permet a Apple de gerer certain fonction plus facilement, et de maniere moins problematique, notamment sur la gestion de memoire (Java peut etre tres complique pour la gestion de la memoire, et de ce que l'on appelle le "garbage collector" qui demande enormement de ressource et de temps, encore plus sur des ressources mobiles) au prix d'un programation simplifee en JAVA (pas de gestion de la memoire implicite)

[Ambroise]

Il faut quant meme comparer ce qui est comparable : les CPU ARM Apple sont comparable a des atom, voire des core i3 pas trop rapides, et Apple n'utilise ni l'atom, ni le core i3.
La seule raison pour Apple de passer a de l'ARM c'est pour faire des marges plus grosses, mais sur quel type de produit ? les portable bas de gamme genre netbook : Apple ne fera jamais de netbook, c'est trop "bas peuple"

Je pense que les marges qui motivent Apple avec un ARM sont essentiellement celles de l'AppStore.
Passer à l'ARM sur un mac n'a clairement aucun intérêt technique : les machines seront très nettement moins rapides qu'avec des x86 et s'ils tentent d'approcher la puissance des processeurs d'entrée de gamme d'Intel alors ces machines, moins efficaces énergetiquement, auront une autonomie inférieure comme on l'a vu récemment avec les constructeurs de Chromebooks.
Par contre il s'agira de machine définitivement fermées : seules les applis validées de l'Appstore seront installables. iCloud sera si bien intégré et les SSD seront si petits que personne n'aura envie de se passer de ce genre de services à haute valeur ajoutée.
A mon avis un Mac ARM sera inutilisable sans Carte Bleue.

[zorphil]

Peut-être des Mac ARM tournant sur une nouvelle mouture d'iOS et les autres toujours sous OS X jusqu'à ce que les deux mondes fusionnent en un seul à l'occasion d'une puissance suffisante des ARM... ?

[Ambroise]

Et c'est bien la le problème, le code natif DEMANDE de l'emulation, non pas comme sur android, qui utilise Java et de la "compilation" a la volée qui simplement transforme le bytecode java en code natif du CPU de la machine (c'est pour cela que android exist sur atom simplement)

Une précision concernant le code natif sur Android :
L'essentiel des applications sont développées en Java, et les applications sont distribuées sous forme de bytecode. C'est lors de leur installation qu'elles sont éventuellement recompilées (à partir du bytecode) pour s'adapter à l'architecture de la cible.
Par contre les parties d'applications qui réclament de la puissance, ou bien dont ont voudrait limiter la consommation de certains traitements sont développées en C++ et compilées en binaire natif. Dans l'immense majorité des cas elles ne sont compilées que pour les ARM.
Intel a développé avec Google des outils qui font de la traduction de binaire ARM vers du x86 et qui permettent d'avoir les deux versions sur Google Play. Cela permet aux Android x86 d'exécuter les applications natives ARM mais c'est loin d'être la panacée. En moyenne la traduction fait perdre 40% d'efficacité par rapport à du cote qui aurait été compilé nativement pour x86.

[JoKerforever]

Je ne vois pas comment cela peut être commercialement tenable de sortir deux gamme comme ça.

Le MacBook Air 12 pouces ou le MacBook Air 13 pouces.
Et des logiciels spécifiques qui tourneront que sur l'un ou que sur l'autre.

A ce moment là on parle d'iPad Pro (avec un clavier) qui fait tourné iOS avec des applications iOS et ce n'est surtout pas un Mac.

Mais peu importe. Je n'ai jamais été intéressé par le MacBook Air, je ne suis donc pas client de ce genre de chose.

Soit Apple change toute la gamme de Mac en ARM parce que c'est valable de faire le changement, soit elle n'y touche pas et le tout reste sur Intel.

Ce message a été modifié par JoKerforever - 16 Jan 2015, 08:00.

[GregWar]

Xcode n'utilise plus le GCC mais le LLVM (Low Level Virtual Machine)
Est-ce qu'une transition a ARM passerait par cette VM ???

Non, ça reste en fait le nom d'un simple compilateur, qui est simplement mieux optimisé pour Objective C (et sans doute Swift) que ne l'est le GCC. En fait, LLVM n'est plus un sigle et les quatre lettres ne se réfèrent plus forcément à une machine virtuelle, vu que le projet a très vite élargi sa mission par rapport à la vocation du début (j'avais d'abord écrit "initiale" mais c'était ambigu).

Je rappelle que les applications disponibles sur OS X (enfin sauf celles en Java) ou iOS sont compilées, à la différence d'Android, qui fonctionne avec une machine virtuelle et une compilation JIT. Là, la question de la transition d'architecture ne se pose plus du tout.

Absolument.
Et encore pour Android, on quitte petit à petit le JIT, mais c'est une autre histoire.

Bien sur qu'il faudra émuler.
Un driver machin-truc: est-ce que le constructeur va le recompiler ?
Pour un périphérique qui est 2 ans ?

Le "il suffit de recompiler en cochant la case" est une belle illusion qu'Apple donne.
Surtout chez Apple qui déprécie 1 framework par an :-)


Dans le même temps, Intel ne va pas se laisser faire en 2 ans.
Il y a 2 ans, on disait qu'Intel allait se faire bouffer sur le mobile et tablette.
Vous avez vu le nombre de machines sous ATOM qui sortent, et à quel prix?
Intel a refait son retard en terme de conso CPU, je pense que c'était leur objectif, et c'est pourquoi on stagne en perfo brute.

Maintenant que le delta n'est plus tellement significatif, est-ce qu'ils ne vont pas relancer la course à la performance?
2 ans ça peut être long, battre un Core i3 d'aujourd'hui ne servira à rien.

De mémoire, il n'y a pas un fondeur qui a su tenir tête à Intel.
Apple reste un newbee, avec beaucoup d'argent certes, et sans doutes d'excellentes réalisation sur Ax, mais est-ce que cela va suffire?

Donc Mac ARM, peut-être dans 2 ans.
Mais perso, je ne suis pas pressé, et surtout, je ne suis pas convaincu que les conditions soient (toujours) favorables, au regard des contraintes que cela va nous imposer.

J'ai connu le 68k, le PowerPC, et franchement, je n'ai jamais été aussi satisfait des perfs que depuis que nous sommes sur Intel.
Quant au "miracle" de l'émulation, on oublie bien vite.
Je vais vous reparler moi du miracle du 7.5.2, des Mac PCI, ou de cette saloperie de PPC Enabler… ou pas… c'est mauvais pour ma tension ;-)

[zloran]

Et pourquoi pas le retour de l'iBook tournant sur iOS avec un processeur ARM qui remplacerais le MacBookAir ?
Comme ça on reste dans la logique de deux systemes complémentaire et de deux architechture independante.
iOS pourrais prendre en charge de nouvelles fonctions (gestion des fichier et port USB) comme quand l'ipad est arrivé.
La rumeur de l'ipad Pro 12" est peu etre lié à la rumeur d'un macbookair 12" c'est peut etre la meme machine ?

[Lionel]

En fait, le plus dur n'est pas tant d'imaginer qu'Apple puisse passer à ARM que de gérer sa crainte que la société le fasse.
Comme je l'ai souvent dit, Apple se permet des choses que certains ne pourront jamais faire grâce à ses clients fidèles. Qu'ensuite ils soient obliger de payer et de galérer est presque un détail.
Maintenant des Mac ARM ? Pourquoi pas, mais je me demande si je vais prendre ce train comme j'ai déjà renoncé à prendre celui de l'Apple Watch ou du Mac Pro façon corbeille.

[fuby]

Il faut quant meme comparer ce qui est comparable : les CPU ARM Apple sont comparable a des atom, voire des core i3 pas trop rapides, et Apple n'utilise ni l'atom, ni le core i3.
La seule raison pour Apple de passer a de l'ARM c'est pour faire des marges plus grosses, mais sur quel type de produit ? les portable bas de gamme genre netbook : Apple ne fera jamais de netbook, c'est trop "bas peuple"

Je pense que les marges qui motivent Apple avec un ARM sont essentiellement celles de l'AppStore.
Passer à l'ARM sur un mac n'a clairement aucun intérêt technique : les machines seront très nettement moins rapides qu'avec des x86 et s'ils tentent d'approcher la puissance des processeurs d'entrée de gamme d'Intel alors ces machines, moins efficaces énergetiquement, auront une autonomie inférieure comme on l'a vu récemment avec les constructeurs de Chromebooks.
Par contre il s'agira de machine définitivement fermées : seules les applis validées de l'Appstore seront installables. iCloud sera si bien intégré et les SSD seront si petits que personne n'aura envie de se passer de ce genre de services à haute valeur ajoutée.
A mon avis un Mac ARM sera inutilisable sans Carte Bleue.

L'apple store n'est qu'un revenue minime de Apple, c'est peanuts, cela "Attire" le client, mais ne lui fait pas debourser du pognon !


clairement : l'avantage c'est de proposer une machine (sous ARM), OS (sous IOS) qui demande pas grand chose, mais surtout, les marges seront enormes sur ce type de machine si il y intel en moins !


dans la cas de la carte mere : pas la peine, tu prends de l'ipad Air
dans le cas de l'écran : pas la peine, tu prends de l'ipad air
dans le cas du design : pas la peine tu prend du macbook air
dans le cas de l'OS : pas la peine tu prend iOS


mais la encore, les marges sur le hardware, comme Apple le fait sur les appareil iOS (iPhone/iPad) qui sont superieures car une grosse partie, notamment le CPU et le GPU ne viennent pas de fournisseur externe.


il ne faut pas oublier que Apple fait des $$$ avec du hardware, pas du software, car cela ne paie pas, sauf sur du service (abonnement), mais apple est a la ramasse et surtout mauvais (avec mobileMe, mac.com, et maintenant icloud)

exemple :
Ipad Air 2 - 128GB - wifi + cellular = 825 euros = larges marges
Macbook air - 11 pouce 128 GB - wifi = 899 euros = petites marges

par contre, un "ipadbook air - 11 pouce 128 GB - wifi + cellular = 899 euros = larges marges ;-)

[McCaron]

cet analyste est aussi célèbre pour ses prédictions foireuses

parce que mis à part prédire des sorties d'iphone et d'ipad qui arrivent chaque année aux mêmes dates, il s'est quand même bien loupé sur beaucoup de choses ces 2 dernières années


ses annonces relèvent plus de la spéculation que de véritables analyses sourcées

[kiw0r]

Hello,

Que le mac passe a l'ARM me gêne pas plus que ça, au contraire, Apple a beaucoup d'expérience avec les ibildules.

Ceci dit, il est clair que ça ne sera pas pour tout le monde, mais avec la généralisation du "clowd" et le fait que les applications vendues par des gros (coucou Adobe) ne soit plus que des abonnements a des machins hébergés, l'applicatif lui même importe peu.

Voire même un coup d'Xcode pour faire un "binaire" FAT (le modèle des .app venant de Next permet d'avoir dedans plusieurs version et libs... c'est un peu ça qui fait la force du biniou comparé aux .exe de nos amis aux fenêtres colorées) avec les choses compilées comme il faut.

Ceci dit, il faut que quand même Apple arrête de péter les API tout le temps s'ils veulent que les dev lâchent pas l'affaire.

D'autre part, vu qu'on voit que Mac OS X (eg 10.10) s'approche de plus en plus a un iOS, on peux largement se demander si le OS X qui fera tourner ces "Mac" sera un iOS avec juste un Finder et impossibilité de faire tourner d'autre chose que ce qui est sur l'App Store.

Si c'est le cas, je prendrais le même train que Lionel c'est à dire : rester sur x86, car j'ai besoin de mes applis Unix low level de mon coté et MacPorts m'aide beaucoup (même si le sandbox apple est souvent désactivé car il me gonfle, genre je peux pas faire tourner OpenOffice mais ouais...).

Après on peux toujours râler sur les larges marges des produits Apple, mais on a justement des trucs qui ont pris du temps a être développé, et on n'as affaire a des photocopieuses qui copient (plus ou moins bien) les produits d'apple, car rappelons bien : Apple récupère un produit qui ne sert a rien chez Xerox, la souris et son interface graphique, il en fait le Mac, Microsoft se fout d'eux, mais quand même en sous marin il récupère un Mac et fait une copie de Mac OS avec Windows ... On peux parler du NeXt qui est toujours en avance sur l'informatique habituelle, qui a été "simplifié" pour faire OS X (oui simplifié car on gardé les extensions de fichiers et le formats à la con, alors que sur NeXt on pouvais faire des choses bien sans se faire <censored> par "j'ai pas word, j'ai pas pages..." pour ouvrir un document ...)... Reste que quand même OS X est une bonne réussite même si j'aurais aimé qu'on jettes HFS+ pour du ZFS...

[McCaron]

En fait, le plus dur n'est pas tant d'imaginer qu'Apple puisse passer à ARM que de gérer sa crainte que la société le fasse.
Comme je l'ai souvent dit, Apple se permet des choses que certains ne pourront jamais faire grâce à ses clients fidèles. Qu'ensuite ils soient obliger de payer et de galérer est presque un détail.
Maintenant des Mac ARM ? Pourquoi pas, mais je me demande si je vais prendre ce train comme j'ai déjà renoncé à prendre celui de l'Apple Watch ou du Mac Pro façon corbeille.

beaucoup ont déjà payé cher le passage du G5 à intel en pensant que ce passage serait perenne...

[Pascal 77]

Donc l'émulation est une fausse considération.

Sauf que tu oublies un détail, l'aspect économique : on parle d'entrée de gamme, là, donc, des machines destinées essentiellement aux particuliers, et vu la politique tarifaire d'Apple, nombre de ces particuliers risquent de ne pas avoir les moyens de racheter le Mac et tout leur parc logiciel en version ARM, ce qui risque de freiner grandement les ventes de ces Mac ARM !

je me demande si je vais prendre ce train

Curieusement, comme je te connais, j'ai du mal à imaginer que, déjà, tu puisse actuellement fonctionner avec des Core i3


Ce message a été modifié par Pascal 77 - 16 Jan 2015, 09:44.

[shawnscott]

Quid de Carbon lors du passage de MacOS 9 à X (bon là on avait les mêmes processeurs) ou d'Universal Binary lors du passage du PowerPC à Intel? On avait des applications avec double code pour pouvoir être exécutées sur deux architectures différentes. Est-ce si difficile dans le cas d'un passage d'Intel vers ARM? (Ceci dit, je ne vois pas l'intérêt pour moi utilisateur de changer une fois de plus de processeur/plateforme…)

[Guest_dtb06_*]

[...]Voire même un coup d'Xcode pour faire un "binaire" FAT (le modèle des .app venant de Next permet d'avoir dedans plusieurs version et libs... c'est un peu ça qui fait la force du biniou comparé aux .exe de nos amis aux fenêtres colorées) avec les choses compilées comme il faut.[...]

Oui, super, le fait de pouvoir faire des "packages" avec plusieurs versions différentes ne permet en rien au développeur d'éviter d'avoir à les fabriquer pour plusieurs architectures !
De plus, sous Windows, les programmes s'installent souvent avec des installateurs (ce qui au passage est moins classe qu'un glisser-déposer dans le répertoire applis, mais laisse en général moins de merdouilles à la désinstallation). Rien n'empêche d'avoir un installateur qui contient plusieurs versions, par exemple une 32 bits et une 64 bits. Si les versions sont souvent séparées par architecture sur les sites de téléchargement, ce n'est souvent que pour limiter leur poids et la bande passante.
Et les EXE, tu es bien gentil, mais je te donne un exemple. Je suis au boulot sous Windows 7, et j'utilise le logiciel Origin version 6 qui date de 1999. Il est en 32 bits, et s'exécute sur toutes les versions de Windows depuis Windows 95, et même sur Windows 10 Preview en 64 bits.
Chez moi j'ai un MBP sous 10.6.8 qui date de 2009, et il lui est impossible de lancer certaines applications OSX qui demandent des versions plus récentes, et à l'inverse, si je l'avais mis à jour avec Yosemite par exemple il m'aurait été impossible de lancer des logiciels PPC pas trop vieux pourtant (Warcraft 3 par exemple).

Alors la "force du biniou" ne réside sûrement pas dans sa souplesse au niveau des versions.

Ce message a été modifié par dtb06 - 16 Jan 2015, 10:08.

[Chicken Mayo]

Il suffit que ca ne s'appelle plus Mac.

Si ce Mac d'entrée de gamme sous ARM s'appelle iPad Pro au lieu de MacBook Air, et homePad/homePadPro au lieu de MacMini/iMac le tour est joué.

Apple aurait 3 gammes de produits:
- les iPad avec des applis ARM
- les iPad Pro/homePad/homePad Pro avec des applis ARM
- des Macs (MacPro et iMac haut de gamme) avec pourquoi pas suffisamment de puissance pour avoir un "rosetta ARM" et pouvoir faire tourner les applis ARM des "homePad".

Ainsi pas de problème marketing:
Le client qui achète un "ipad version ordinateur" sais qu'il en pourra faire tourner que des applis achetée sur le store (et ne songera jamais à y faire tourner une application "mac"). Ce qu'il faut c'est une offre logicielle adaptée (office, photoshop elements, etc...) afin que la machine soit considerée comme un vrai ordinateur.

[SartMatt]

Voire même un coup d'Xcode pour faire un "binaire" FAT (le modèle des .app venant de Next permet d'avoir dedans plusieurs version et libs... c'est un peu ça qui fait la force du biniou comparé aux .exe de nos amis aux fenêtres colorées) avec les choses compilées comme il faut.

Un .app n'est rien d'autre qu'un dossier dont le Finder t'empêche de visualiser le contenu directement par double clic... À l'intérieur, il y a bien des binaires distincts pour chaque archi. (faux, cf : http://forum.macbidouille.com/index.php?sh...p;#entry3935318 )
Exactement comme sous Windows ou le dossier d'une application peut contenir un exe 32 bits et un exe 64 bits. Ou même, pour que ça soit transparent, un exe 32 bits et un exe 64 bits cachés, et un troisième exe 32 bits non caché qui servira juste de lanceur pour détecter si la machine est 32 ou 64 bits et aller chercher le bon exe caché.

Nul besoin d'émulation car les applications seront natives, et la transition se résumera a une case a cocher dans xCode dans le meilleur des cas et a une adaptation de l'interface dans le pire des cas.

Tu sais, il y a des applications qui ne sont jamais passées au x86, donc il y en aura forcément aussi qui ne passeront pas à l'ARM... Par exemple parce que l'éditeur l'a abandonnée (ou carrément parce qu'il n'existe plus...) ou encore parce qu'il voudra en profiter pour vendre une nouvelle version de l'application... Et même quand le portage sera fait, ça va pas être instantané : au lancement, énormément d'applications manqueront !

Rappelons aussi que MacOS n'est pas le premier a passer a ARM, Microsoft l'a fait (même si des considération marketing n'ont pas poussées a la réussite commerciale)

Ben oui bien sûr, si ça a pas marché, c'est forcément à cause du marketing C'est pas du tout par exemple parce que les tablettes Windows x86 offrent le même rapport performances/prix mais avec une logithèque bien plus large...

et cela fait depuis très longtemps que les Unix, Linux en tête et Android fonctionnent sur ARM et x86… sans que l'utilisateur s'en rendent compte.

Ah ben oui, forcément, l'utilisateur s'en rend pas compte : dans 99% des cas il tourne en x86...

L'emulation lors des passage du 68k au PowerPC et du PowerPC a Intel était nécessaire du fait que le marche Mac était restreint, que les developpeurs codaient pour un microprocesseur et qu'il n'y avait que le Mac, ses 5% de PDM et c'est tout.

Aujourd'hui Apple est un leader avec des milliers de développeurs qui programment depuis des années pour iOS, donc ARM.

Sauf qu'une application iOS n'est pas une application OS X. C'est flagrant, regarde la quantité d'applications iOS qui n'ont pas été portées sous OS X et inversement. Ça montre bien que soit c'est pas aussi simple que tu veux bien le faire croire, soit tout simplement que la plateforme OS X n'intéresse pas les développeurs iOS (et c'est clairement pas pour une question d'architecture, il n'y a aucune raison que le passage à l'ARM rende soudain la plateforme plus attractive pour les développeurs iOS).

Niveau de la puissance, c'est pareil. On le voit avec l'iPad Air, dont le processeur est surdimensionne, il fait aussi bien qu'un MBA de 2011

Dans Geekbench, c'est ça ?
Dans la réalité, les processeurs ARM les plus puissants d'aujourd'hui sont encore largement en dessous d'un Core i3. Ils parviennent à dépasser les Atom Bay Trail, mais sont plus proches de ces derniers que des i3...

On voit ces deux derniers années la multiplication des mini-PC ARM Android/linux

On voit les références se multiplier, parce que ça coûte pas cher à concevoir. Question vente, c'est une autre affaire par contre... En dehors des stick HDMI à brancher aux TV, on ne trouve quasiment aucun PC ARM chez les revendeurs "mainstream" (et encore, même les stick HDMI, on en trouve peu), uniquement chez des revendeurs spécialisés, à la clientèle un peu geek... Et il y a aussi parmi ces geeks beaucoup de déçus du Raspberry Pi qui finissent par se tourner vers des mini-PC x86 pour en avoir un peu plus sous la pédale...

[Pascal 77]

Quid de Carbon lors du passage de MacOS 9 à X (bon là on avait les mêmes processeurs) ou d'Universal Binary lors du passage du PowerPC à Intel? On avait des applications avec double code pour pouvoir être exécutées sur deux architectures différentes. Est-ce si difficile dans le cas d'un passage d'Intel vers ARM?

Difficile, non, mais on en revient toujours au problème de l'intégralité du parc applicatif à renouveler, parce que celui qui investit aujourd'hui quelques milliers d'€ (voire quelques dizaines de milliers) n'achète que du code "Intel", le jour où une partie de son parc passe en ARM, il doit tout racheter pour avoir de l'UB, et s'il passe tout son parc en ARM, il doit tout racheter pour avoir de l'ARM !

Tu sais, il y a des applications qui ne sont jamais passées au x86, donc il y en aura forcément aussi qui ne passeront pas à l'ARM... Par exemple parce que l'éditeur l'a abandonnée (ou carrément parce qu'il n'existe plus...) ou encore parce qu'il voudra en profiter pour vendre une nouvelle version de l'application... Et même quand le portage sera fait, ça va pas être instantané : au lancement, énormément d'applications manqueront !

+1 : On a déjà vu ça au passage du PPC à l'Intel, et il y a aussi le cas de nombre d'applications qui n'ont jamais eu de mises à jour "Intel", parce qu'un peu anciennes, leurs éditeurs savaient que les ventes ne pourraient pas amortir les frais du portage, résultat, aujourd'hui, j'ai le choix entre rester sous 10.6.8, ou les abandonner !

Quant à l'émulation, faut pas rêver, j'ai eu l'occasion de tester, à l'époque des premiers Mac Intel, au moyen d'une macro "Excel" spécialement dédiée à cet effet, les performances comparées d'un PowerBook G4 à 1,5 Ghz, avec celles d'un MBP CoreDuo 1,83 Ghz (le tout premier) en émulation PPC (Excel 2004) : c'était à peu près équivalent, grâce, ainsi que ça a été précisé plus haut, à l'écart de performances entre le CoreDuo et le G4, mais j'ai beaucoup de mal à imaginer un processeur ARM capable, en émulation, d'approcher seulement des performances d'un C2D, sans même parler de celles d'un Core i3 !

Ce message a été modifié par Pascal 77 - 16 Jan 2015, 11:30.

[Webtourist]

Je suis d'accord avec les analyses qui émettent l'idée qu'à moyen terme, ARM restera cantonné à iOS, et OSX à x86.
Ce qu'on va peut-être observer à court terme, c'est une modification des OS qui pilotent les différents appareils à la pomme.

Pour l'instant, iOS ne pilote que les iPhone, iPad et TV; et OSX tous les autres (Air, MB, iMac, MP)

On pourrait imaginer qu'Apple veuille étendre le pilotage par iOS et restreindre le périmètre d'OSX. Ainsi on aurait :

iOS: TV, iPhone, iPad + iPad Pro + MB Air + mini (je vois bien une fusion à terme de TV et Mini)
OSX : MBP/iMac/MP

Naturellement, Apple glisserait ainsi jusqu'à ce que iOS/ARM gère tous les appareils grand-public, et OSX mourant à petit feu sur les MBP/iMac/MP qui vont encore disparaître évoluer, laissant le temps ainsi à tous les éditeurs majeurs de sortir leur version iOS.

Autant Apple que MS tous deux ont intérêt à n'avoir qu'un seul cœur d'OS, et différentes interfaces pour les différents usages. Ainsi la question n'est pas de savoir SI la tendance des OS est au cœur unique, elle l'est, mais plutôt QUAND et surtout COMMENT.
Pour Apple, pas de transition radicale je pense, mais plutôt en douceur via une augmentation des appareils pilotés par un coeur iOS/ARM

Ce message a été modifié par Webtourist - 16 Jan 2015, 12:10.

[Pensee]

La Pomme est un produit perissable !


honetement je ne suis pas presse, meme si cela excite ma curiosite. une nouvelle version de system chassant l'autre, nous perdons le support (maj securite) de ce qui est notre outils de travail. les nouvelles versions n'apportant pas grand chose (si ce n'est des bugs). il est difficile de juste vouloir garder les chose en l'etat avec maj de securite. cette fuite en avant technologique a bien des reverts, Apple est responsable de ne pas avoir su garder une simplicite autour des fontionalites de base.

perso je me fous de iOS, le raprochement iOS OsX n'a que des inconvenients (X.9, X.10).Je souhaite garder mes habitudes le plus longtemps possible, meme si je doit me deconnecter avec mon Mac ce qui est possible (mais pas commode). une machine puissante c'est pour produire, une machine ARM pourrait completer a cote pour etre connecter.

la principale question etant de ne pas cesser de produire. et la Apple n'aide pas vraiment. Grrrr!!!!

[Tophe974]

Un .app n'est rien d'autre qu'un dossier dont le Finder t'empêche de visualiser le contenu directement par double clic... À l'intérieur, il y a bien des binaires distincts pour chaque archi.

Pas du tout : un .app est effectivement un répertoire contenant l'exécutable et les resources, mais le binaire, lui est bel et bien un binaire "fat", contenant toutes les architectures.
Exemple pour l'application Firefox :

$ lipo -info /Applications/Firefox.app/Contents/MacOS/firefox
Architectures in the fat file: /Applications/Firefox.app/Contents/MacOS/firefox are: x86_64 i386

Et c'est le loader qui choisit l'architecture la plus appropriée, même si tu peux forcer l'ouverture en 32bits.

Ce message a été modifié par Tophe974 - 16 Jan 2015, 12:59.