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.

[elbacho]

En fait Apple, pourrait attendre encore un an ou deux ... ça me rappelle quelque chose, les écrans flexible :

En 2010 on commence à nous dire que Samsung a présenté des écran souple "indestructible " … avec une production de masse prévue en 2012.
http://www.macbidouille.com/news/2010/07/2...-indestructible

EN 2012 on nous annonce la fameuse production de masse …
http://www.macbidouille.com/news/2012/03/0...-oled-flexibles

EN 2013 on nous annonce que les écrans Samsung se faisant attendrent … ils allaient se faire griller par LG, qui aurait démarré la production en masse de se type d’écran.
http://www.macbidouille.com/news/2013/06/2...-fin-de-l-annee

Encore en 2013 on nous annonce carrément la guerre (LG vs Samsung), allant même jusqu’à parier que c'est une des choses qu'attend Apple pour son iWatch …
http://www.macbidouille.com/news/2013/08/2...ientot-demarrer

Q’en est il en 2015 ? soit presque 5 ans après ?

Ce message a été modifié par elbacho - 16 Jan 2015, 12:54.

[SartMatt]

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 choisis l'architecture la plus appropriée, même si tu peux forcer l'ouverture en 32bits.

En effet... Du coup comment marche des applications comme Xslimmer qui peuvent supprimer les archis "en trop" dans les applications universelles ? Ça modifie le binaire ?

EDIT : j'ai ma réponse sur Wikipedia : "Mac OS X does include the lipo and ditto command-line application to remove versions from the Multi-Architecture Binary image."
Je me coucherais moins bête ce soir :-)

[r@net54]

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?

Les quelques machines qui sortent équipées d'Atom existent parce qu'Intel paie une maximum les constructeurs pour qu'ils aient au moins une reference histoire de rassurer les financiers. Ce comportement vide les caisses d'Intel, c'est clairement du dumping et sans ça il n'y aurait pas de mobile avec Atom (on va voir avec les Core M, mais ça risque d'être la meme chose vu les déceptions unanimement constatées sur les premières machines équipées).
En plus s'il fallait que les constructeurs financent la R&D pour intégrer une architecture qui se vendra de manière anecdotique ce serait contre productif. Le problème est le meme avec Microsoft et la plateforme WindowsPhone: tant que MS payait pour qu'un constructeur ait une reference il y en avait, mais a l'arrêt des "subventions" les constructeurs laissent tomber et aujourd'hui après des années de subventions en en pure perte 95% des Windows Phone sont des Lumia de Microsoft… Il en va de meme avec les surface, qui pourtant sont sous x86, la conception des versions ARM ayant été abandonnées par MS pratiquement des leur lancement pour des raisons purement marketing.

Niveau prix de revient Intel ne peut se confronter aux SoC ARM, ni meme en terme de performance par watt effective. Si ARM a acquis le marche du mobile cela c'est fait sur des années et en convainquant avec des performances et une autonomie remarquable qu'Intel ne peut pas atteindre avec l'architecture x86.
En plus Intel n'est pas une société capable de vivre sur un marche concurrentiel, son ADN c'est le monopole, et sur les marches ARM la concurrence est féroce.


Apres, lorsque les observateurs constatent qu'un iPad est équivalent en performance a une Macbook Air en terme de puissance, faut se remettre en tete que l'on compare un processeur conçu pour du mobile face a un un Core i5. On ne compare pas un ARM et un Atom.
Il en va de meme avec les mini PC ARM qui sortent a foison ces derniers temps: ils sont construit comme des smartphone, pas comme des machines de bureau, et pourtant niveau performance ils tiennent la route.

Et finalement si aucun fondeurs faisant du x86 n'a pu tenir face a Intel, c'est grâce aux pratiques anti concurrentielles d'Intel, pratiques qui l'oui on valu des condamnations.
Sinon, tous les processeurs AMR, Power, Mips,… ne sont pas produits par Intel: Intel ne produit que du x86, et tous les x86 ne sont pas produit par Intel…

Et faut aussi recentrer le débat sur la réalité: on parle aujourd'hui des possibilités qu'Intel aurait pour prendre une petite PDM sur les marches du mobile, de la capacité de résister d'Intel face a l'arrivee d'ARM sur les marches du PC, du serveur, du HPC…
Il y a 2 ans évoquer la simple idée qu'un jour ARM équiperait un PC portable faisait passer sont auteur pour un fou, et penser simplement qu'Intel serait menacer sur serveur par AMR était pour quantité de gens inconcevables… maintenant ce ne sont plus des hypothèses et on voit a quel point ces réalités oblige Intel a mener une bataille désespérée pour sauver son x86…

En fait Apple, pourrait attendre encore un an ou deux ... ça me rappelle quelque chose, les écrans flexible :

En 2010 on commence à nous dire que Samsung a présenté des écran souple "indestructible " … avec une production de masse prévue en 2012.
http://www.macbidouille.com/news/2010/07/2...-indestructible

EN 2012 on nous annonce la fameuse production de masse …
http://www.macbidouille.com/news/2012/03/0...-oled-flexibles

EN 2013 on nous annonce que les écrans Samsung se faisant attendrent … ils allaient se faire griller par LG, qui aurait démarré la production en masse de se type d’écran.
http://www.macbidouille.com/news/2013/06/2...-fin-de-l-annee

Encore en 2013 on nous annonce carrément la guerre (LG vs Samsung), allant même jusqu’à parier que c'est une des choses qu'attend Apple pour son iWatch …
http://www.macbidouille.com/news/2013/08/2...ientot-demarrer

Q’en est il en 2015 ? soit presque 5 ans après ?

La différence c'est que les processeurs ARM sont une réalité économique qui a capte pratiquement 100% du marche, pour l'instant mobile, marche qui aujourd'hui comprend aussi quelques petits PC. Ce que l'on evoque c'est des machines qui aujourd'hui tournent avec des Core i5 et Core i7 qui vont être remplace par des ARM de niveau desktop, et pas des simple Chromebook.
Et dans le monde du serveur, ça fait plus de 2 ans que l'architecture en en cours de certification.

L'ecran flexible finira par être commercialise, comme l'OLED finira par devenir majoritaire, car les problèmes qui se posent sont au niveau de la production industrielle de masse, pas au niveau de la conception.
Et puis on voit aussi une grosse différence, le LCD rigide a toujours une grosse marge d'évolution et les progrès qui sont fait depuis 2 ans sont énorme et constatables. Pour le x86, ce n'est pas le cas, Intel tente de grappiller les derniers recoins d'optimisation mais les core stagnent désespérément depuis Sandy bridge, alors certes les Core ix sont aujourd'hui des SoC dont la partie graphique a fait des énormes propre depuis le GMA, mais niveau core, on est sur la meme puissance qu'il y a 5 ans et en terme de consommation ça n'a pas beaucoup avance en réalité (par contre la gestion électrique elle c'est énormément complexifiee).
Du cote d'ARM, avec Apple en tete on voit l'évolution et la marge de progression de cette évolution qui n'est même pas en terme d'optimisation mais bien de progression de puissance et d'innovation d'architecture...

Pour ARM la grosse difficulté pour qu'il se répande sur PC était le passage a 64 bit, Apple a pris tout le monde cours en sortant une version 64 bit au moins 2 a 3 ans en avance sur le calendrier prévu, et on voit que les concurrents peine a rattraper leur retard, et alors qu'Apple travaille a l'optimisation de son architecture 64 bit, les autre essayent encore de faire en sorte que ça marche, et c'est pas gagne. Mais d'ici 6 mois chaque producteur aura un ARM 64, et la ça va sérieusement menacer le x86.

Ce message a été modifié par r@net54 - 16 Jan 2015, 14:11.

[MacMobile]

Est-ce qu'une transition a ARM passerait par cette VM ???

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).

Merci, je doutais un peu du VM du nom :-)
D'un autre cote, dans les codes sources Apple on peut voir certaine app avec les code iOS et Mac dans le même projet.
C'est peut être un autre indice ?

[El Bacho]

Q’en est il en 2015 ? soit presque 5 ans après ?

Les dates devaient elles-mêmes être flexibles.

Je vais aller plus loin que ce que j'avais dit sur le sujet depuis le départ, quitte à me prendre une volée de bois vert de la part de r@net54. Ces rumeurs de transition programmée sont du vent.

C'est certain qu'Apple, avec son équipe de développement d'architecture ARM, étudie la faisabilité d'une transition, notamment en cas de percée dans la performance des puces ARM. Ils ont des centaines de personnes qui planchent sur les processeurs Ax, ils peuvent se permettre d'en prendre cinq ou vingt de plus pour mener une veille technologique ou réaliser des prototypes de processeurs ARM à plus forte dissipation thermique destinés à des portables ou des machines de bureau. Avec en parallèle des gens d'OS X qui font des builds sous ARM, déjà que le noyau et quelques API sont très très proches d'iOS sous ARM.

Mais il n'y a aucune raison valable pour qu'Apple ait décidé d'entamer la transition des Macs vers une architecture ARM. Les dirigeants actuels sont bien moins capricieux que Steve Jobs, ça n'aiderait absolument pas les parts de marché, et l'utilisateur s'en ficherait au mieux, vu qu'il ne gagnerait rien dans l'affaire.

MacBidouille publie des rumeurs en ce sens depuis mai dernier. Si on relit la première, rien dans les affirmations fournies par la source ne s'est vérifié à ce jour :
http://www.macbidouille.com/news/2014/05/2...n-a-des-mac-arm

Pas d'annonce d'iMac, Mac mini ou MacBook 13 pouces avec processeur ARM. Et aucun nouveau clavier avec un Magic Trackpad grand format, qui n'avait d'ailleurs pas besoin des Macs ARM pour être lancé (et ça serait débile : le Mac mini est fourni sans clavier, et je n'imagine pas une seconde que l'on fasse un clavier prolongé par un Magic Trackpad sur la droite, rien qu'à cause des gauchers, sans parler du fait que les utilisateurs Mac de bureau apprécient encore la souris)

Il n'y a pas non plus de site qui a repéré de build étrange d'OS X dans ses logs, fonctionnant sous une architecture non précisée (alors qu'on a déjà des cas de machines sous OS X 10.11). Donc on a des prototypes de Macs qui n'ont jamais été reliés à Internet, tellement c'est un projet secret (mais avancé), et ce projet est parfaitement connu d'une taupe qui a été à Cupertino (ou qui connaît quelqu'un qui a été à Cupertino), qui n'avait contacté que MacBidouille pour diffuser cette info.

Mouais, mouais, mouais....

Mouais....

Et pour une rumeur toute aussi fantaisiste de la même source en septembre :

http://www.macbidouille.com/news/2014/09/0...ont-en-approche


Pour la persistance de ces rumeurs, je vois là trois raisons distinctes :

1) La hype concernant les puces Ax dans laquelle sombrent quelques uns.
"Wow ! Les puces A8 d'Apple en 64 bits, elles ont paraît-ils les performances d'un PC. Si ça se trouve, elles pourraient remplacer les puces des Macs ! Alors je vais dire qu'elles vont le faire"

2) La détestation d'Intel façon cour de récré
"Intel, c'est caca beurk et has been. Il faut aller sur ces puces ARM, qui seront forcément hyper-méga-meilleures que les Intel, et Apple va certainement vouloir le faire, parce que je déteste Intel."

3) L'envie de jouer à se faire peur
"J'aime de moins en moins les choix faits par Apple. Du coup, je vais apporter un peu de crédit à une rumeur abracadabrante, parce que je suis tellement déçu par eux que je me dis qu'ils pourraient carrément faire une grosse connerie comme basculer les Macs sous ARM."

Bien entendu, si j'ai tort, et que les Macs ARM débarquent bien d'ici deux ans, je suis prêt, comme le premier réalisateur bavarois venu, à manger mes propres chaussures :

http://www.vanityfair.fr/culture/cinema/ar...-paris-perdu/73

[Heret]

... il serait aujourd'hui certes possible de proposer un processeur ARM doté de 8 ou 16 c&oelig;urs puissants...

Un transatlantique met 5 jours pour aller du Havre à New York, combien faut-il de transatlantiques pour faire le trajet en une demi-journée ?

[Montréal]

Et s'il s'agissait d'un pas de plus vers l'externalisation des logiciels ? Dans ce cas, peu importe le processeur et l'OS. Vous vous connectez chez Apple et vous utilisez Page, etc… Apple pourrait proposer aux développeurs d'intégrer leur modèle économique. Sachant que les ordinateurs Apple ont de moins en moins de connecteurs, c'est possible voire même probable d'en arriver là à moyen terme.

[SartMatt]

tant que MS payait pour qu'un constructeur ait une reference il y en avait, mais a l'arrêt des "subventions" les constructeurs laissent tomber et aujourd'hui après des années de subventions en en pure perte 95% des Windows Phone sont des Lumia de Microsoft… Il en va de meme avec les surface

Il en va de même avec les Surface ? Tu veux dire que 95% des tablettes Windows sont des Surface ? Lol... Les ventes de Surface par rapport aux autres tablettes Windows sont anecdotiques... Le gros du marché, c'est sans doute Asus, dont la T100 a fait un carton (plus d'un an et demi après sa sortie, elle est encore en 9ème position des ventes d'ordinateurs portables chez Amazon...), et Lenovo.

Niveau prix de revient Intel ne peut se confronter aux SoC ARM

Et pourquoi donc ? Un cœur Bay Trail est plus petit que certains coeurs ARM d'aujourd'hui (par exemple celui de l'A8), donc y a pas de raison qu'il revienne plus cher, et en prime Intel vend aussi des puces bien plus haut de gamme sur lesquelles il peut amortir le gros de ses usines.

ni meme en terme de performance par watt effective

Ça tu auras beau le répéter, ça ne changera rien au fait que tous les tests faits ces dernières années prouvent le contraire... Intel et ARM sont désormais dans un mouchoir niveau consommation, parfois avec un léger avantage pour Intel, parfois un léger avantage pour des implémentations ARM.

En plus Intel n'est pas une société capable de vivre sur un marche concurrentiel, son ADN c'est le monopole, et sur les marches ARM la concurrence est féroce.

C'est vrai que sur le marché du HPC, qui était très concurrentiel, Intel n'a pas du tout réussi à vivre. Et encore moins à passer en quelques années d'acteur minoritaire à acteur majoritaire Vraiment, la concurrence ils savent pas du tout la gérer

Apres, lorsque les observateurs constatent qu'un iPad est équivalent en performance a une Macbook Air en terme de puissance, faut se remettre en tete que l'on compare un processeur conçu pour du mobile face a un un Core i5.

Et faut se mettre en tête que tu compares une machine 10" qui tient 10h de surf avec une batterie de 27 Wh, soit une cosommation moyenne de 2.7W dans cet usage et une machine 13" qui tient 12h de surf avec une batterie de 54 Wh, soit une consommation moyenne de 4.5W... Si tu tiens compte de l'écran plus grand, des I/O bien plus évoluées (les contrôleurs USB, PCI-Express, TB, SATA, etc... ça consomme), on se rend bien compte que l'écart de consommation du CPU n'est pas si grand dans cet usage... Tout en ayant beaucoup plus de souplesse, le CPU étant capable d'offrir des performances nettement supérieures dans les tâches gourmandes.

Et finalement si aucun fondeurs faisant du x86 n'a pu tenir face a Intel, c'est grâce aux pratiques anti concurrentielles d'Intel, pratiques qui l'oui on valu des condamnations.

Pas seulement. AMD n'a quasiment jamais réussi à faire le poids sur le haut de gamme, là où se font les marches.

de la capacité de résister d'Intel face a l'arrivee d'ARM sur les marches du PC, du serveur, du HPC…

Cette année, Intel est en croissance de 3% sur le PC, de 25% sur les datacenter... Dure l'arrivée d'ARM

Il y a 2 ans évoquer la simple idée qu'un jour ARM équiperait un PC portable faisait passer sont auteur pour un fou, et penser simplement qu'Intel serait menacer sur serveur par AMR était pour quantité de gens inconcevables… maintenant ce ne sont plus des hypothèses

Euh si, ce sont toujours des hypothèses. Enfin non, pour toi ça s'apparente plus aux rêves qu'aux hypothèses. Mais pour les gens raisonnables, ça reste des hypothèses.
Par exemple, là où ton rêve te fait prétendre qu'une puce ARM d'aujourd'hui pourrait sans problème remplacer un Core i5, la réalité montre que non, et les gens raisonnables font l'hypothèse que dans deux ans Apple aura peut-être enfin une puce ARM dont les performances soient comprises entre un Atom et un Core i3, ce qui lui permettrait de commencer à utiliser du ARM dans les Mac.

Du cote d'ARM, avec Apple en tete on voit l'évolution et la marge de progression de cette évolution qui n'est même pas en terme d'optimisation mais bien de progression de puissance et d'innovation d'architecture...

Tiens, ça fait longtemps que tu nous en avis pas parlé de cette formidable marge de progression dont tu nous rabâches les oreilles. Mais il suffit pas de le dire, faudrait le prouver qu'elle existe cette marge énorme, alors que les faits commencent à montrer ce que je te dis depuis des années : l'architecture ARM a pu connaitre une forte croissance des performances il y a quelques années, car elle partait de très loin, mais maintenant qu'elle se rapproche des autres, ça s'essouffle et ça progresse beaucoup moins vite... Regarde la courbe de progression des performances des iPhone ou des Nexus, c'est absolument flagrant que les gains s'amenuisent fortement d'année en année... Les modèles 2014 n'ont gagné que 10-20% par rapport à ceux de 2013, et encore, seulement dans les cas les plus favorables...

Je vais refaire une analogie que je fait souvent : le gamin qui décide de se mettre à l'athlétisme, c'est des poignées de secondes qu'il va gagner sur le 400m pendant ses premiers mois d'entrainement... Mais plus il va s'approcher des records, plus il va avoir du mal à progresser, la progression ne va plus se compter en secondes, mais en dixièmes puis en centièmes... Et même si au début il s'approchait rapidement du record, il est loin d'être certain qu'il le battra un jour...

[Crapouilleau]

La différence c'est que les processeurs ARM sont une réalité économique qui a capte pratiquement 100% du marche, pour l'instant mobile, marche qui aujourd'hui comprend aussi quelques petits PC. Ce que l'on evoque c'est des machines qui aujourd'hui tournent avec des Core i5 et Core i7 qui vont être remplace par des ARM de niveau desktop, et pas des simple Chromebook

Des ARM qui ont la puissance d'un i5 ou i7 desktop?
Si tu sais fabriquer de tels processeurs je te conseille de te lancer ; tu vas faire un carton car tu dois bien être le seul.

[Ambroise]

Les quelques machines qui sortent équipées d'Atom existent parce qu'Intel paie une maximum les constructeurs pour qu'ils aient au moins une reference histoire de rassurer les financiers. Ce comportement vide les caisses d'Intel, c'est clairement du dumping et sans ça il n'y aurait pas de mobile avec Atom (on va voir avec les Core M, mais ça risque d'être la meme chose vu les déceptions unanimement constatées sur les premières machines équipées).

Intel fait clairement du dumping mais pas sur les marchés visés par le Core M.
Sur le marché mobile (chez Intel ça veut dire "les SoCs munis de modem"), Intel a des SoCs qui sont certes efficaces sur le rapport perf/watts mais qui sont dépourvus de modem intégré : cela impose un surcoût élevé pour l'achat du modem et son intégration au côté du SoC. La politique d'Intel a été de compenser ce surcoût auprès de leurs clients jusqu'à ce qu'ils puissent proposer des SoCs intégrants ces modems (type SoFIA 3G et SoFIA LTE 2). Ils ont fait des pertes massives à cause de cette politique.

Les Atoms et les Core M que l'ont trouve sur les tablettes sont eux particulièrement lucratifs pour Intel et leur dernières incarnations ont un rapport performances/watts hors de portée des ARM de Qualcomm ou de Samsung. Il n'y a qu'à voir la déferlante de nouveaux Chromebooks à base de processeurs Broadwell ou Bay-Trail. Même Samsung a annoncé une version musclée de son chromebook 2 11 pouces dont l'ARM (pourtant un Samsung Exynos Octa maison) est remplacé par un Celeron Bay-Trail qui augmente à la fois les performances (beaucoup) et l'autonomie (un peu).

[Guest_dtb06_*]

Et on l'a bien vu depuis la chute d'AMD (post -AthlonX2, depuis 2007), Intel se contente d'une progression CPU de 20% de perfs par an. Pas parce qu'ils ne savent pas faire, mais parce qu'ils n'ont plus de concurrence. Du coup ils gardent leurs marges.
Si un ARM arrive un jour à concurrencer frontalement Intel, c'est très simple, ils vont baisser au max le prix des modèles basse conso (Atom, Core Uxxx), peut être en perdant de l'argent dessus, mais en se rattrapant sur le haut de gamme (i7/i5 et surtout Xeon) sur lesquels personne ne les concurrencera.

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.

Encore une fois : oui, peut-être qu'il y a les deux dans le paquet, mais ça n'empêche pas qu'il y a quand même un mec à la base qui a été obligé de coder pour deux architectures différentes. Ce n'est pas parce que tu codes un truc pour un processeur ARM que magiquement ton compilateur te sort une version x86 à côté.
C'est comme si j'offre un CD et un livre à ma petite cousine, je peux très bien faire un seul paquet global donc un seul cadeau, ça ne m'empêcheras pas d'avoir à acheter les deux séparément !

Ce message a été modifié par dtb06 - 16 Jan 2015, 18:35.

[SartMatt]

Et on l'a bien vu depuis la chute d'AMD (post -AthlonX2, depuis 2007), Intel se contente d'une progression CPU de 20% de perfs par an. Pas parce qu'ils ne savent pas faire, mais parce qu'ils n'ont plus de concurrence. Du coup ils gardent leurs marges.

L'absence de concurrence est quand même loin d'être la seule raison. Il y en a aussi deux autres, qui jouent sans doute bien plus (car même en l'absence de concurrence, Intel aurait intérêt à augmenter le plus possible les performances, pour pousser au renouvellement et pour limiter le risque qu'un concurrent revienne) :
- depuis la débacle du Pentium 4 Prescott, Intel met l'accent sur la consommation, et préfère donc parfois laisser un peu de performances au profit d'une consommation réduite,
- les limites de la physique sont ce qu'elles sont, et plus on s'en approche, plus il devient difficile et coûteux de s'en approcher... En particulier, les chaînes de production gravant toujours plus fin sont de plus en plus chères.

Encore une fois : oui, peut-être qu'il y a les deux dans le paquet, mais ça n'empêche pas qu'il y a quand même un mec à la base qui a été obligé de coder pour deux architectures différentes. Ce n'est pas parce que tu codes un truc pour un processeur ARM que magiquement ton compilateur te sort une version x86 à côté.

Non, pas nécessairement. Il y a quand même énormément de choses qu'on peut faire de façon totalement indépendante de l'architecture sur laquelle ça va tourner. Un programme écrit en C, C++, Objective-C, etc... pourra se compiler quasi indifféremment sur x86 et ARM.

C'est surtout quand on a besoin de ne faire aucune concession sur les performances qu'on doit adapter le code spécifiquement à l'architecture cible (même quand on ne code pas directement en assembleur !). Et c'est là qu'il va y avoir un gros problème en cas de passage à l'ARM : non seulement ces optimisations seront à refaire, mais en plus, elles seront beaucoup plus nécessaires, du fait des performances moindres.

[AlxV]

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.

Microsoft a sorti une tablette ARM tout comme Apple a sorti une tablette ARM

Dans le cas d'Apple, le monde entier a applaudi des deux mains en félicitant IOS et ses nouvelles applications, et personne, oui, personne, ne s'est émeu que les tablettes iOS ne puissent faire tourner la logithèque OS X

Dans le cas de Microsoft, la majorité des gens, et même les plus intelligents et les plus informés, se sont tiraillés de douleur et d'incompréhension comme quoi la surface RT était incapable de faire tourner la logithèque Windows x86

C'est surtout pour ça que Microsoft a jeté l'éponge

... enfin aussi parcequ'en même temps ils ont sorti une surface Pro qui elle était sous x86 avec un vrai Windows, du coup c'était incompréhensible pour les consommateurs. Si Apple avait sorti un iPad PRO sous x86 avec OSX en même temps que l'ipad, ce dernier n'aurait surement pas connu le succès qu'il a eu, et, surtout, les tablettes ne seraient que des ordinateurs sans clavier et avec un stylet, ce qui est, rappelons le, une hérésie

Conclusion : la surface Pro est une hérésie

[Ambroise]

Et on l'a bien vu depuis la chute d'AMD (post -AthlonX2, depuis 2007), Intel se contente d'une progression CPU de 20% de perfs par an. Pas parce qu'ils ne savent pas faire, mais parce qu'ils n'ont plus de concurrence. Du coup ils gardent leurs marges.

Dans les faits ils ne gardent pas de marge. L'impression d'une croissance modérée de la puissance provient de la segmentation des offres d'ordinateurs et de processeurs. Apple décide par exemple que les nouveaux Mac mini seront un peu moins puissants que les précédents, alors que les nouveaux processeurs dispos auraient permis de faire très nettement augmenter cette puissance.

L'augmentation de la puissance de calcul des processeurs d'Intel, dans le même segment, est forte et continue.
Si on se contente de ne regarder que la puissance brute de calcul, sans tenir compte du fait que l'essentiel des gains de puissance ces dernières années s'est fait en dehors du processeur et particulièrement sur les GPU, on obtient tout de même une croissance très supérieure à 20% par an.

En prenant les meilleurs scores de chaque année du bench SpecFP Rate pour les machines mono-processeur (en multi on obtiendrait une augmentation encore plus rapide de la puissance de calcul) on obtient :

Code

SpecFP 2006 Rate

Dec-2014    Intel Xeon E5-2699v3 2300Mhz    474
Nov-2013    Intel Xeon E5-2697v2 2700Mhz    345
Jun-2012    Intel Xeon E5-2690 2900Mhz      257
Dec-2011    Intel Core i7-3960X 3300Mhz     200
Nov-2010    Intel Xeon X7560 2267Mhz        141
Oct-2009    Intel Xeon W5590 3333Mhz        108
Nov-2008    Intel Core i7-965 3200Mhz       86.1    
Nov-2007    Intel Core 2 QX9650 3000Mhz     52.0

Soit 450% en 5 ans (xeons) bien que la fréquence ait baissé de 30% (dans les faits elle a augmenté mais Intel a tendance à communiquer davantage sur la fréquence minimale).

Et si on remonte à 2007, le meilleure score de l'année était tenu par le Pentium D 940 à 3,2Ghz. Il obtenait 18. 7 ans plus tard le Xeon E5-2699 v3 calcule 26 fois plus vite mais il consomme autant d'énergie.

[SartMatt]

(dans les faits elle a augmenté mais Intel a tendance à communiquer davantage sur la fréquence minimale)

Petite précision : la fréquence minimale garantie en charge, pas minimale tout court ;-)
Sur les Haswell, la fréquence minimale est de 800 MHz.

Et sur les gammes grand public, Intel communique désormais plutôt sur la fréquence maximale du mode turbo plutôt que sur la fréquence de base.
Par exemple, dans la base ARK, le titre des fiches reprend derrière la référence la quantité de cache et la fréquence turbo sur les Core ("8M Cache, up to 4.40 GHz" par exemple pour le i7 4790K, dont la fréquence de base est 4 GHz), alors que pour un Xeon c'est la quantité de cache et la fréquence de base ("15M Cache, 3.50 GHz" par exemple pour le E5-1650v3, qui monte à 3.8 GHz en turbo).

[Ambroise]

(dans les faits elle a augmenté mais Intel a tendance à communiquer davantage sur la fréquence minimale)

Petite précision : la fréquence minimale garantie en charge, pas minimale tout court ;-)
Et sur les gammes grand public, Intel communique désormais plutôt sur la fréquence maximale du mode turbo plutôt que sur la fréquence de base.

Effectivement. Mais ça paraît plutôt sensé comme communication.
Pour le Xeon E5-2699 v3 il est clair que lorsque les 36 threads sont utilisées en pleine charge en continu, la fréquence ne doit pas monter au-dessus des 2,3Ghz de fréquence de base indiqués - et on imagine que ce genre de processeur est destiné à absorber des charges de calcul lourdes et permanentes.
J'imagine que pour le Core i7 4790K la mention "up to 4,4Ghz" correspond bien à sa cible ceux qui ont besoin d'une fréquence très élevée même si ça se fait à un moment donné avec des contraintes sur le nombre de coeurs qui atteignent cette fréquence.

[iFrodo]

Personnellement je suis pour le développement des processeurs ARM sur le maximum de plateformes possibles, car c'est une architecture ouverte, tout le monde peut contribuer à son évolution, et ses bases sont bien meilleures que le x86 ("patché" en x86_64 par AMD pour le 64bits).

Aujourd'hui c'est effectivement encore trop tôt pour le desktop, mais au train ou vont les choses, je n'ai pas le moindre doute que cela soit une alternative intéressante. D'autant que le besoin de Windows est beaucoup moins important que par le passé, ce dernier étant en perte de vitesse et la popularité de la plateforme Mac (et à bien moindre mesure de Linux), a amené les éditeurs de grands noms de logiciels tel que Autodesk a finalement supporter OS X.
Sans compter que Windows a aussi sa version ARM, qui certes n'a pas eu beaucoup de succès (faute d'une stratégie efficace de Microsoft (ex: Imposer par défaut la compilation en Fat Binary) ), mais qui pourrait être à nouveau poussé par Microsoft si les processeurs ARM deviennent compétitif (Microsoft étant loin d'être le dernier à vouloir une alternative à Intel).

Bref, autant il y a ne serait ce que 5 ans, j'aurais trouvé tout autre choix qu'Intel aurait été une erreur monumental, autant d'ici 2 à 3 ans, le choix ARM sera loin d'être stupide, bien au contraire.

[kwak-kwak]

Personnellement je suis pour le développement des processeurs ARM sur le maximum de plateformes possibles, car c'est une architecture ouverte, tout le monde peut contribuer à son évolution, et ses bases sont bien meilleures que le x86 ("patché" en x86_64 par AMD pour le 64bits).

Sauf que dans le contexte actuel "l'ouverture" n'est que de façade et est plutôt est plutôt un frein à l'innovation: chacun fait son truc dans son coin sans aucune concertation et dès qu'il y en a un qui met en place une innovation, il interdit aux autres d'user ou d'améliorer cette dernière via une batterie de brevet (parfois triviaux).

Bref, autant il y a ne serait ce que 5 ans, j'aurais trouvé tout autre choix qu'Intel aurait été une erreur monumental, autant d'ici 2 à 3 ans, le choix ARM sera loin d'être stupide, bien au contraire.

Intel va aussi progresser durant cette même période et je ne serais même pas étonné qu'Apple finisse par abandonner complètement ARM pour proposer des solutions 100% x86 sur l'ensemble de ses produits. Par ailleurs migrer de l'ARM vers le x86 (et depuis iOS) est infiniment plus simple que de faire l'opération inverse. Car dans ce sens là on peut encore obliger les développeurs indépendants à mettre à jours leurs appli (qui auront bien du mal à se passer des ventes d'iTunes) alors que de grosses maisons d'éditions abandonnent déjà OSx pour passer chez Windows et commencent à réfléchir au portage sur Linux. De plus quand on passe de l'ARM au x86, l'émulation est bien plus simple.

Ce message a été modifié par kwak-kwak - 17 Jan 2015, 10:08.

[El Bacho]

Car dans ce sens là on peut encore obliger les développeurs indépendants à mettre à jours leurs appli (qui auront bien du mal à se passer des ventes d'iTunes) alors que de grosses maisons d'éditions abandonnent déjà OSx pour passer chez Windows et commencent à réfléchir au portage sur Linux. De plus quand on passe de l'ARM au x86, l'émulation est bien plus simple.

Les parts de marché du Mac sont en augmentation. À part les éditeurs de logiciels de comptabilité, qui sont ces fameuses grosses maisons d'édition qui abandonneraient OS X et qui réfléchiraient à un portage sur Linux, à la part de marché et à la croissance plutôt inférieures, et qui est beaucoup moins unifié, avec une myriade de distribs qui peuvent compliquer le support ?

Sans parler du fait qu'entre deux Unix, il est simple d'avoir du code commun qu'entre un Unix et Windows...

[Ambroise]

Personnellement je suis pour le développement des processeurs ARM sur le maximum de plateformes possibles, car c'est une architecture ouverte, tout le monde peut contribuer à son évolution, et ses bases sont bien meilleures que le x86 ("patché" en x86_64 par AMD pour le 64bits).

Moi aussi. J'espère que les archis ARM vont monter sur de nouveaux marchés et continuer à progresser. La concurrence ça n'a que des aspects positifs dans ce genre de domaines.

Par contre l'archi ARM est loin d'être ouverte, bien au contraire. Le jeu d'instruction a quitté le domaine public après l'ARMv2 il y a 20 ou 25 ans. Contrairement au x86, c'est une architecture faisant l'objet de licences et ces licences sont très restrictives et empêchent toute contribution ou tout ajout d'instructions. C'est l'architecture fermée par excellence. Du temps ou Intel était un fabriquant de processeurs ARM de premier plan (avec les XScale) ils avaient fait les frais de cette politique avec l'obligation d'implémenter leurs instructions Wireless MMX en dehors des opcodes natifs : en gros chaque instruction bien qu'intégrée au processeur devait être invoquée par un appel externe de périphérique ce qui en faisait chuter artificiellement les performances.

A l'inverse, le x86 est une architecture publique et ouverte. AMD, Cyrix, Nec, Zilog, Transmeta, VIA, IBM, NexGen, Texas Instruments et bien d'autres ont conçu ou on fabriqué des processeurs compatibles (Zilog s'étant illustré il y a 40 ans sur les compatibles 8080), parfois sous licence mais généralement avec leur propre R&D sans aucun compte à rendre à un quelconque propriétaire. Et il existe plusieurs implémentations opensource ou openhardware de l'archi x86. (Cette situation a priori idyllique est toutefois à relativiser vu les différents brevets déposés par AMD, Intel et VIA sur des noms d'instructions ou sur des encodages d'opcodes qui rendent plus complexe l'arrivée de nouveaux concepteurs).
Et le x86 tel qu'on le connaît aujourd'hui est le fruit des contributions de plusieurs acteurs, la plus connue étant bien sûr le x86-64 d'AMD.

Pour ce qui est l'aspect "patché" du x86 face aux bases saines d'ARM, j'ai une tendance spontanée à adhérer à l'évidence de cette théorie tant ma formation universitaire m'a convaincu de la perfection et de la supériorité du RISC face aux conceptions brouillonnes et malsaines de l'inventeur du microprocesseur.

Mais les faits sont têtus. Le jeu d'instruction x86 est extensible par nature (car ses instructions sont codées sur une longueur variable). Force est de constater que l'architecture x86 a réussi à passer en trente ans du secteur de l'embarqué, à celui des ordinateurs de moyenne puissance, pour dominer maintenant celui des supercalculateurs tout en maintenant le jeu d'instruction et en l'étendant par l'ajout de nouveaux opcodes.

ARM a connu un succès encore plus fulgurant en passant du domaine des ordinateurs de forte puissance (avec l'Archimedes qui battaient les 386 tout en coûtant 3 fois moins cher) à celui de l'embarqué et en devenant au passage numéro un mondial des architectures de processeur. Mais pour assurer l'évolution, le jeu d'instruction à taille fixe (par nature inextensible) a du être patché à plusieurs reprises et les incarnations actuelles de l'architecture ARM utilisent plusieurs jeux d'instructions indépendants pour maintenir la compatibilité. Pour ajouter des instructions spécialisées (instructions vectorielles, cryptage) il faut faire des appels d'extensions comme dans les années 80 quand ces instructions étaient implémentées dans des puces externes.

Vue la facilité avec laquelle Intel et AMD peuvent ajouter de nouvelles instructions, j'ai tendance à penser que l'architecture x86 a un potentiel d'évolution supérieur à celui de l'architecture ARM. L'évolution des jeux d'instructions vectorielles chez Intel, leur prise en charge d'instructions à 5 opérandes (VEX prefix), ou de flux de calculs dédiés à la mémoire GDDR (comme sur les GPUs) avec les Xeon Phi,.... tout cela laisse l'impression que les percées qui ont vu le jour ces dernières années en matière d'ISA concernent avant tout la vénérable architecture x86.

Et tout cela se fait avec une ISA qui se décline aussi bien dans des boutons de chemise à consommation quasi nulle que sur des processeurs de calcul à 60 coeurs.

[SartMatt]

et ses bases sont bien meilleures que le x86 ("patché" en x86_64 par AMD pour le 64bits)

Tu pourrais expliciter en quoi le x86_64 serait plus un "patch" que le ARM 64 bits ?

Sauf que dans le contexte actuel "l'ouverture" n'est que de façade et est plutôt est plutôt un frein à l'innovation: chacun fait son truc dans son coin sans aucune concertation et dès qu'il y en a un qui met en place une innovation, il interdit aux autres d'user ou d'améliorer cette dernière via une batterie de brevet (parfois triviaux).

Tout a fait. Alors que dans le monde x86, les accords de licence sont généralement des accords croisés (au moins entre AMD et Intel et entre Intel et VIA, je sais pas pour VIA et AMD), ce qui fait que quand l'un des fabricant développe de nouvelles extensions, les autres peuvent les utiliser.

[r@net54]

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.

Microsoft a sorti une tablette ARM tout comme Apple a sorti une tablette ARM

Dans le cas d'Apple, le monde entier a applaudi des deux mains en félicitant IOS et ses nouvelles applications, et personne, oui, personne, ne s'est émeu que les tablettes iOS ne puissent faire tourner la logithèque OS X

Dans le cas de Microsoft, la majorité des gens, et même les plus intelligents et les plus informés, se sont tiraillés de douleur et d'incompréhension comme quoi la surface RT était incapable de faire tourner la logithèque Windows x86

C'est surtout pour ça que Microsoft a jeté l'éponge

... enfin aussi parcequ'en même temps ils ont sorti une surface Pro qui elle était sous x86 avec un vrai Windows, du coup c'était incompréhensible pour les consommateurs. Si Apple avait sorti un iPad PRO sous x86 avec OSX en même temps que l'ipad, ce dernier n'aurait surement pas connu le succès qu'il a eu, et, surtout, les tablettes ne seraient que des ordinateurs sans clavier et avec un stylet, ce qui est, rappelons le, une hérésie

Conclusion : la surface Pro est une hérésie

C'est en partie vrai, mais il reste aussi un élément marketing majeur qui est la rentabilité lie au prix de vente.
Aujourd'hui la production de tablettes ARM est très rentable pour Apple, qui maitrise la totalité du matériel, rentable pour Samsung (en tout cas sur les modèles 9"), peut être rentable pour Lenovo et éventuellement Asus, qui peuvent se permettre de vendre avec une belle marge leurs tablettes. Pour les autres c'est comme les smartphones, c'est difficilement rentable.

Pourquoi les fabricants essayent dans ces conditions d'etre a tout prix (c'est le cas de le dire) sur le marche mobile: parce que le marche PC est en récession et que le mobile semblait être la releve avec des croissances inconnues depuis des années. QU'importe alors de vendre a perte, l'important était de se faire une place et de capturer une PDM pour garder des clients captifs: veille recette du onde PC Wintel.

On voit Intel avec le meme raisonnement qui est oblige de gérer des pertes colossales liees aux Atom. Si Intel maintient cette machine a perdre de l'argent depuis 2008, et que chaque année il lui faut "acheter" un peu plus cher des PDM artifielement, c'est parce qu'Intel a tout a perdre si la société n'arrive pas a se faire meme une peine place sur le mobile. Aujourd'hui on estime qu'un Atom est "vendu" entre $3 et $5 pour concurrencer les processeurs ARM. Le hic c'est qu'a $5 une ARM est rentable, un Atom c'est a partir de $30 pour les plus petits modèle et ça monte a près de $100, surtout si on compte que pour Intel faut budgeter les efforts monstrueux de la société nécessaire pour faire évoluer les Atom (ne serait ce pour passer en 64 bits - ça a l'air de rien comme ça mais c'est loin d'être simple, y a qu'a voir les difficultés de Qualcomm avec son 810…). Mais l'Atom, meme a ce prix plus que bradé, reste une déception et il faut qu'Intel "subventionne" les Atom directement pour les fabricants, notamment en participant largement a la R&D, l'industrialisation, voire meme en achetant des stock entier de produit fini pour en garantir le prix de vente… Alors oui on voit quelques produits motorises avec des Atom, mais il s'agit d'une goutte d'eau lorsque l'on compare a la masse de produits ARM, et le gros problème pour Intel c'est que les performances des ARM grimpent en meme temps que le prix d'achat des ARM diminue: on voit les fondeurs chinois qui aujourd'hui produisent de l'A9 et de l'A17 a des couts défiants toute concurrence, permettant de sortir des mini PC sous les $100 et des tablettes 9" sous les $150, et cela en garantissant des marges…

Donc Microsoft est dans ces conditions dans une position délicate. C'est pas que la société soit incapable de vendre a perte pour se faire une grosse PDM, c'est le cas de tout ses produits, a part les clavier/souris. Mais la situation avec la tablette AMR était très différente a cause de la forte concurrence.
Microsoft comme Intel sont des sociétés qui ont un modèle économique base sur le monopole et la position dominante.
Tout le système de Microsoft est organise autour de la dépendance a Windows, et tout nouvel élément doit renforcer cette dépendance. Avec la tablette ARM, Microsoft a fait une erreur majeure en terme de marketing. La tablette, n'ayant pas été financee suffisamment et peut être pour ne pas se mettre complètement a dos Intel, est sortie sans être compatible avec le marche Windows. Microsoft a donc sorti une machine nouvelle avec un OS nouveau et innovant, face aux leader du marches: iOS et Android. Sans la sacro-sainte retrocompatibilite qui est le dogme de Wintel, la Surface restait un outsider qui devait démontrer une supériorité et un intérêt économique face a l'écosystème iOS et a l'hypeconcurence Android…

Microsoft, se rendant compte de ça a préféré je ter l'éponge et abandonner le secteur de la tablette. On le constate, la Surface Pro n'est pas vendu comme une tablette, ni meme un TabletPC, mais comme un Ultrabook.
C'est finement joue, car ça permet a Microsoft un positionnement tarifaire eleve et ça evite les comparaisons performances/autonomies des univers Android et iOS. Les Surfaces Pro sont comparees donc a des Ultrabook, voire des portables, qui font tourner Windows!

Microsoft a vu juste dans ce rattrapage marketing, on le voit face a la domination indéboulonnable d'iOS et Android.
Apres, Microsoft a aussi couvert ses arrière. Se lancer dans la conception d'une tablette ARM voulait dire soit attaquer les performances des machines d'Apple et de Samsung, soit se battre sur les tarifs des chinois. Microsoft était incapable de faire l'un ou l'autre et conserver sa position dans le train de sénateur motorise par Intel était une solution raisonnable.

Maintenant le souci c'est qu'Intel n'arrive toujours pas apres des années de guerre économique a surpasser ARM et qu'ARM commence a devenir présent dans tous les secteurs informatique, depuis l'embarque jusqu'au HPC.
Pire encore, si on reste dans le monde mobile, on voit que non seulement la puissance des processeur a une croissance qui fait rêver le x86, mais que cela se fait en meme temps que l'optimisation énergétique progresse aussi.

Du cote du x86 la puissance de calcule brute stagne apres une forte progression jusqu'en 2005:


Du cote ARM c'est l'inverse, et on le voit notamment avec les processeurs équipant les iPhone et iPad:


Et Apple n'est pas le meilleur en terme de puissance. NVIdia qui vient de pressente de Tegra x1, explose les performances de tout le reste.


Le monde ARM est donc dans une course a la puissance et a l'efficacité énergétique soutenu par une concurrence très dynamique. Si le passage aux 64bit a représente une pose dans cette course a la puissance, cela va repartir de plus belle maintenant.

Pire encore pour Intel, si on regarde la courbe de progression de puissance du GPGPU, puissance de calcul brute, on voit que c'est la aussi la courbe est fortement au désavantage du x86.


On le constate, la sortie du tout x86 est surtout liee a des réalités technologiques et puisqu'Intel s'entête a stagner en voulant conserver le juteux monopole etablit sur l'archaïque x86, le marche lui passe a des solutions qui offrent des perspectives d'avenir. Et cela est a l'avantage du client, qui se retrouve avec un matériel innovant, soutenu par une concurrence dynamique et qui a aujourd'hui le choix de pouvoir opter pour l'éditeur/constructeur qui lui offre le meilleur outil.

Ce message a été modifié par r@net54 - 17 Jan 2015, 18:16.

[SartMatt]

On voit Intel avec le meme raisonnement qui est oblige de gérer des pertes colossales liees aux Atom. [...] Le hic c'est qu'a $5 une ARM est rentable, un Atom c'est a partir de $30 pour les plus petits modèle et ça monte a près de $100

Attention, la gamme Atom ne se limite pas aux mobile... La division mobile est déficitaire, mais ce déficit est probablement en grande partie compensée par les bénéfices faits avec les différents dérivés du Bay Trail sur PC et serveurs (il y a des puces Bay Trail qui dépassent les 150$ : 171$ pour l'Atom C2750, 161$ pour le Pentium N3540...).

Quand à la rentabilité, tu délires... 100$, c'est le prix de vente de certains Atom, pas leur seuil de rentabilité ! Et à l'inverse, il y a des Atom qui ne seraient clairement pas rentables à 5$ hein...
Mais ce qui est certain, c'est qu'aujourd'hui le seuil de rentabilité d'un Atom est du même ordre de prix que celui d'un ARM équivalent : ce sont des puces du même ordre de complexité, qui nécessitent à peu près autant de silicium, il n'y AUCUNE raison valable que l'une revienne 6 à 20 fois plus cher (ce sont tes chiffres) que l'autre...

surtout si on compte que pour Intel faut budgeter les efforts monstrueux de la société nécessaire pour faire évoluer les Atom (ne serait ce pour passer en 64 bits - ça a l'air de rien comme ça mais c'est loin d'être simple, y a qu'a voir les difficultés de Qualcomm avec son 810…)

Où l'on découvre à quel point tu ne sais vraiment pas de quoi tu parles Juste comme ça pour info, l'Atom est passé en 64 bits dès la gamme Diamondville, dont les premiers modèles sont sortis en septembre 2008, contre avril 2008 pour les tous premiers Atom... C'est dire la difficulté qu'a dû avoir Intel à passer en 64 bits
Depuis, tous les Atom sont 64 bits, même si le support du 64 bits n'est pas toujours activé, pour des raisons marketing.

Et pareil avec les Pentium 4, le 64 bits est arrivé via une évolution mineure du Prescott. Il semblerait qu'en x86 le passage au 64 bits n'ait vraiment pas été une difficulté...

Pas sûr que ça soit beaucoup plus compliqué dans le monde ARM. Les difficultés de Qualcomm sur le Snapdragon 810 ne viennent sûrement pas du 64 bits d'ailleurs, puisqu'ils ne conçoivent pas le cœur d'exécution (c'est du Cortex A57/A53), mais visiblement plutôt d'autres choses : peut-être le passage au 20nm (hypothèse la plus probable, vu que le retard serait lié à des problèmes de surchauffe, une conséquence classique d'une mauvaise maitrise d'un processus de gravure) ? le big.LITTLE ? ou encore l'une des nouvelles fonctions que vont gérer ce SoC (combinaison des images de deux caméras, Dolby Atmos, annulation de bruit de fond, WiGi à 4 Gbit/s, intégration de Shazam...).

Donc Microsoft est dans ces conditions dans une position délicate. C'est pas que la société soit incapable de vendre a perte pour se faire une grosse PDM, c'est le cas de tout ses produits, a part les clavier/souris.

Décidément, tu es en forme aujourd'hui pour débiter des âneries au kilomètre... Donc Microsoft vendrait tous ses produits à perte, sauf les claviers et souris ? La vache, ils doivent en vendre un sacré paquet pour arriver à éponger toutes les pertes des autres produits et faire en prime 22 milliards de bénéfice annuel

Tout le système de Microsoft est organise autour de la dépendance a Windows, et tout nouvel élément doit renforcer cette dépendance.

Donc quand Microsoft sort Office sur le web et sur iOS et Android par exemple, c'est pour renforcer la dépendance à Windows ?

On le constate, la Surface Pro n'est pas vendu comme une tablette, ni meme un TabletPC, mais comme un Ultrabook.

Oui, mais alors un ultrabook sans clavier et sans souris (vendus en option) et qui s'utilise avec un écran tactile... Je sais pas comment t'appelle ça, mais moi j'appelle ça une tablette...

Maintenant le souci c'est qu'Intel n'arrive toujours pas apres des années de guerre économique a surpasser ARM et qu'ARM commence a devenir présent dans tous les secteurs informatique, depuis l'embarque jusqu'au HPC.

Ça c'est ta vision étriquée des choses... La réalité, c'est qu'en 2014 Intel a repris beaucoup plus sur le mobile à ARM (Intel est devenu le second fournisseur de CPU pour tablettes hors Apple, derrière Qualcomm, et à peu près tout le monde s'accorde à dire qu'ils seront premier d'ici deux ou trois ans) qu'ARM n'en a repris à Intel sur les autres secteurs... Les ordinateurs portables et de bureau à ARM sont encore anecdotique (et malgré tout, ARM a réussi à perdre des parts sur le marché des laptops, avec les Chromebook qui reviennent sur du x86), et c'est à peine mieux sur les serveurs (où Intel a annoncé une croissance de 25% cette année), et encore pire sur le HPC (la part du x86 dans le top 500 est au plus haut, tandis qu'ARM n'y est toujours pas entré).

Pire encore, si on reste dans le monde mobile, on voit que non seulement la puissance des processeur a une croissance qui fait rêver le x86

T'as peur de rien dis donc... Regarde l'évolution des performances des iPhone sur les 4/5 dernières années, ou celle des Nexus sur la même période, et tu verras un net infléchissement de la courbe de croissance en 2014 (valable aussi chez d'autres constructeurs bien sûr). C'est pas comme si je te l'avais déjà expliqué 40 fois

Voilà par exemple les tests de Anandtech sur les Nexus 5/6 et iPhone 5S/6 : http://anandtech.com/show/8687/the-nexus-6-review/4
Gain moyen de la génération 2014 par rapport à la 2013 : 21.2% sur les Nexus, 28.3% sur les iPhone

Et le test du même Anandtech sur les Nexus 4/5 et iPhone 5/5S : http://anandtech.com/show/7517/google-nexus-5-review/4
Gain moyen de la génération 2013 par rapport à la 2012 : 78.4% sur les Nexus, 64.9% sur les iPhone

Et voilà pour les iPhone 4/4S/5 (dans le test du Nexus 4 chez Anand il y a trop peu de comparaisons avec le Galaxy Nexus) : http://anandtech.com/show/6330/the-iphone-5-review/10
Gain moyen de la génération 2012 par rapport à la 2011 : 107% sur les iPhone
Gain moyen de la génération 2011 par rapport à la 2010 : 105% sur les iPhone

On voit donc bien que la croissance qu'on a connu il y a quelques années n'est vraiment plus là. Tiens, comme sur x86... Et ça correspond exactement à ce que je prédisais déjà à l'époque : ARM progressait vite parce que ça venait de très loin, mais fini par se prendre un mur, comme toutes les autres architectures. Il n'y a pas de miracles, les autres architectures sont surtout limitées par la physique et ARM n'est pas au dessus des lois de la physique...

Du cote du x86 la puissance de calcule brute stagne apres une forte progression jusqu'en 2005:

http://i.pcworld.fr/1296385-superpi-32m-historique-hwbot.png

Rhooo... Ce qui est chouette avec toi, c'est que comme tu nous ressors toujours les mêmes trucs bidons, il suffit de te redonner les réponses de l'époque (là et là)...
Donc je te le répète, vu que ça ne veut pas rentrer : une courbe présentée comme ça amplifie fortement l'impression de stagnation, puisque forcément quand tu doubles les performances en passant de 6000 à 3000 secondes, ça donne l'impression d'un progrès visuelle d'un progrès beaucoup plus gros que quand tu doubles les performances quelques années plus tard en passant de 60 à 30s...

Il suffit, plutôt que de faire la courbe du temps de calcul, de faire la courbe de la vitesse de calcul (les performances du CPU, c'est bien la vitesse de calcul, pas le temps de calcul), en décimales par seconde, pour se rendre compte que ce qui stagne, c'est ton argumentaire, pas la puissance de calcul des processeurs :


Et comme je te l'ai déjà maintes fois rappelé, Super Pi est un benchmark qui ne prend en compte ni les nouvelles instructions des CPU (même pas le MMX il me semble...) et qui n'utilise qu'un seul cœur. Dans la réalité, les gains de performances globaux depuis 2000 sont donc largement supérieurs à ceux observés sur Super Pi, grâce au passage de 1 à 4 cœurs, voir plus, et grâce aux nouvelles instructions, qui sont largement utilisées par tous les logiciels ayant besoin de performances maximales.

C'est un benchmark qui est encore beaucoup utilisé dans les concours d'overclocking, pour des raisons historiques (on cherche toujours à battre le record du précédent, être le premier à faire un score sur un nouveau benchmark est moins intéressant... si demain je décide de faire un chrono sur une course de 105m35 à reculons, je deviendrais le recordman du monde du 105m35 à reculons, mais ça ne vaudra rien par rapport à un titre de recordman du monde du 100m...), mais que plus personne n'utiliser pour juger des performances d'un processeur moderne...

Accessoirement, les scores pris en compte pour réaliser cette courbe ne sont pas les scores des meilleurs CPU du commerce, mais ceux des records d'overclocking. Ce n'est donc pas représentatif de la réalité des CPU disponibles sur le marché, les gains obtenus par overclocking n'étant pas forcément les mêmes à chaque génération de processeur. Les premières générations de Core 2 avaient par exemple un très fort potentiel d'overclocking, alors que les Core i d'aujourd'hui en ont un peu moins.

Du cote ARM c'est l'inverse, et on le voit notamment avec les processeurs équipant les iPhone et iPad:
http://hexus.net/media/uploaded/2014/10/c2...7e94af4b84e.jpg

Ah ben tiens, là comme par hasard tu nous prends une courbe de la vitesse de calcul, et pas du temps de calcul... Tu essayerais de nous enfumer que tu ne t'y prendrais pas autrement
Et puis c'est la courbe de performances donnée par Apple, donc tu peux être certain qu'elle prend en compte la multiplication des cœurs et les nouvelles instructions. Et que c'est une mesure dans le meilleur des cas, pas une moyenne ("up to"...).

Enlève ne serait ce que la prise en compte des cœurs multiples, et tu verras que la courbe ne sera pas plus glorieuse que celle de la vitesse des puces x86 sur Super Pi que je t'ai mise juste au dessus.

Si le passage aux 64bit a représente une pose dans cette course a la puissance, cela va repartir de plus belle maintenant.

Dans la réalité, on constate que cette pause ne semble pas liée au passage au 64 bits : chez Apple, le ralentissement des gains de performances intervient après le passage au 64 bits, chez les autres il intervient avant... Le point commun, c'est qu'il intervient chez tout le monde en même temps. De là à supposer que ça n'a rien à voir avec le 64 bits mais plutôt avec le fait qu'on commence à atteindre les limites de ce qu'on peut tirer d'un CPU qui doit rentrer dans un smartphone, il n'y a qu'un pas...

[SartMatt]

Pire encore pour Intel, si on regarde la courbe de progression de puissance du GPGPU, puissance de calcul brute, on voit que c'est la aussi la courbe est fortement au désavantage du x86.

Alors là tu m'as tué (de rire)... On se rend encore plus compte d'à quel point tu parles de choses que tu ne maitrises absolument pas, au point de nous sortir des courbes sans même prendre la peine de vérifier ce qu'elles représentent ! Et surtout, ça montre à quel point tu es près à balancer la première info qui te tombes sous la main sans prendre la peine de vérifier ce que ça représente et de te demander si c'est fiable (mais ça, on l'a déjà vu avec ta tentative de manipulation via la comparaison des courbes de temps de calcul d'un côté avec des courbes de vitesse de calcul de l'autre...).

Tu nous dis qu'il s'agit d'une courbe de puissance de calcul brut, alors qu'il suffit de regarder la légende en haut à gauche pour voir qu'il s'agit de la bande passante mémoire, pas de la puissance de calcul... Bien sûr, il y a un lien indirect entre les deux, mais c'est vraiment très loin d'être totalement corrélé... Faut pas oublier par exemple que les processeurs x86 embarquent d'énormes caches, qui les rendent moins dépendant de la bande passante mémoire... Là où un Kepler GK110 dispose d'1.5 Mo de cache L2 partagé entre tous ses threads (il y en a 2880...) et de 64 Ko de L1 partagé par groupe de 192 threads, un Xeon E7 v2 à 15 cœurs peut embarquer jusqu'à 37.5 Mo de L3 partagé entre ses 30 threads en plus de 256 Ko de L2 et 64 Ko de L1 par groupe de 2 threads (1 cœur)... Et même un simple Core i3 Haswell a ces 256 Ko + 64 Ko de cache L2 + L1 par 2 threads et 3 Mo partagés entre ses 4 threads.

À noter aussi que si tu prolongeais ta courbe jusqu'à 2014, il y aurait un resserrement... Aujourd'hui les Xeon E7 v2 ont 85 Go/s de bande passante mémoire, 160% de plus qu'en 2010, alors qu'un GK110 en a 336, "seulement" 75% de plus qu'en 2010...

[Ambroise]

Pire encore pour Intel, si on regarde la courbe de progression de puissance du GPGPU, puissance de calcul brute, on voit que c'est la aussi la courbe est fortement au désavantage du x86.

Alors là tu m'as tué (de rire)... On se rend encore plus compte d'à quel point tu parles de choses que tu ne maitrises absolument pas, au point de nous sortir des courbes sans même prendre la peine de vérifier ce qu'elles représentent ! Et surtout, ça montre à quel point tu es près à balancer la première info qui te tombes sous la main sans prendre la peine de vérifier ce que ça représente et de te demander si c'est fiable (mais ça, on l'a déjà vu avec ta tentative de manipulation via la comparaison des courbes de temps de calcul d'un côté avec des courbes de vitesse de calcul de l'autre...).

Je n'arrive pas à trancher : est-ce que r@net54 est un troll qui balance des inepties pour le plaisir de provoquer des réactions ? ou est-ce qu'il ne comprend réellement pas le sens des tableaux qu'il reproduit ?
J'en arrive à me demander s'il n'essaie pas de ridiculiser la communication d'Apple en la caricaturant et en en grossissant les points les plus risibles. En regardant ses multiples interventions de ces derniers mois sur la croissance de puissance des ARM face à l'indigence des x86, il paraît évident que les Apple Ax doublent leurs performances toutes les 3 semaines et que le Commissariat à l'Energie Atomique va remplacer les dizaines de milliers de Xeons de ses supercalculateurs par 4 iPhones.
Sous ses dehors d'illuminé qui n'entrave que dalle aux aspects techniques se cache peut-être un employé de Microsoft qui tente de faire passer les utilisateurs de Mac pour des enragés incapables de réflexion ou d'auto-critique tant ils seraient aveuglés par leur haine anti-Microsoft et anti-Intel....

[SartMatt]

[r@net54]

Il suffit, plutôt que de faire la courbe du temps de calcul, de faire la courbe de la vitesse de calcul (les performances du CPU, c'est bien la vitesse de calcul, pas le temps de calcul)

Eh bien entendu le temps de calcul n'a strictement rien en commun avec la vitesse de calcul...
Au fait on mesure la vitesse, comment deja?
Allez un petit coup de Wikipedia pour te rafraichir les idees: De manière élémentaire, la vitesse s'obtient par la division d'une mesure d'une variation (de longueur, poids, volume, etc) durant un certain temps par une mesure du temps écoulé.

Je te rappelle que meme en traitement parallèle, l'element de base du calcul, c'est le temps que met une unite de traitement (un core) pour traiter l'instruction prenant le plus de temps a traiter... A partir de la on peut faire une projection qui donnera une valeur statistique qui sera la vitesse du calcul, que ce soit a minima, a maxima ou en moyenne!

Ce qui est signifiant pour la puissance de traitement, c'est le nombre d'instructions traitées par unites de temps mais aussi le volume et la complexité de données traitées par unite de temps. Donc ce qui est signifiant pour la puissance, c'est le temps de calcul!
Pouvoir executer x instructions par cycle c'est bien, la question est de savoir si c'est a la suite ou en parallèle... Parce que la signification est pas la meme et le resultat n'a alors pas la meme implication:
pouvoir executer 3 instructions en parallèle dans le cas ou le traitement ne peut se faire qu'une instruction apres l'autre, ca veut dire que par cycle on a alors 2 operations nulles pour une operation signifiante! Ce qui veut dire que la quantites de donnees traitee par unite de temps est une information cruciale pour la puissance de traitement, et donc du processeur!

Evidemement il ne s'agit pas de la vitesse de transmission des donnees, qui est certes importantes pour eviter de creer un goulet d'etranglement, mais bien de la quantite de donnees traitees: et cela est encore plus significatif dans le calcul vectoriel, celui dans lequel sont specialises les GPGPU...

Et comme je te l'ai déjà maintes fois rappelé, Super Pi est un benchmark qui ne prend en compte ni les nouvelles instructions des CPU (même pas le MMX il me semble...) et qui n'utilise qu'un seul cœur. Dans la réalité, les gains de performances globaux depuis 2000 sont donc largement supérieurs à ceux observés sur Super Pi, grâce au passage de 1 à 4 cœurs, voir plus, et grâce aux nouvelles instructions, qui sont largement utilisées par tous les logiciels ayant besoin de performances maximales.

Tu racontes n'importe quoi.
Que tu me denigres parce que mon argumentaire contredis tes croyances c'est une technique rethorique comme une autre, mais denigrer un programme comme super PI, ca va un peu loin.

En fait ce que tu es en train d'insinuer c'est que Super PI n'evalue pas l'efficacite des autres architectures (unitee vectoriel, coprocesseur,...) qui sont embarquées dans les SoC x86...

Super PI est justement un des rares logiciel capables d'evaluer la puissance de calcul brute et lineaire d'un processeur. Il demontre un resultat comparable depuis des annees: la puissance de calcul brute d'un core!
Ses resultats ne sont pas manipulés du fait que tel type de calcul a ete donné a une unite (un coprocesseur) a la place du core, qu'un type d'instruction aura ete optimisee pour les bench, etc... Tu peux comparer un processeur d'il y a 10 an avec un processeur actuel et avoir un resultat fiable.
Le fait que les x86 d'aujourdhui sont des SoC, n'est pas une mauvaise chose en soi, puisque ca permet de compenser les limites de d'une vielle architecture. Et heureusement que les unites vectorielles existent dans ces SoC, parce que sinon tout ce qui est traitement "multimedia" ne serait simplement pas possible.
Mais dans les faits, la puissance de calcul du core, Super PI demontre bien la realite de la progression. Et quand tu dois faire du calcul non vectoriel, ce qui va compter c'est justement ce qu'evalue Super PI.
Donc tu peux denigrer ce programme parce qu'il derange tes croyances, en attendant ses resultats sont significatifs pour toute personne qui s'intéresse a la veritable puissance de calcul du core.

Accessoirement, les scores pris en compte pour réaliser cette courbe ne sont pas les scores des meilleurs CPU du commerce, mais ceux des records d'overclocking. Ce n'est donc pas représentatif de la réalité des CPU disponibles sur le marché, les gains obtenus par overclocking n'étant pas forcément les mêmes à chaque génération de processeur. Les premières générations de Core 2 avaient par exemple un très fort potentiel d'overclocking, alors que les Core i d'aujourd'hui en ont un peu moins.

Décidément, tu raconte n'importe quoi, du moment que ca t'arrange, et le dénigrement est une habitude.
Puissance de calcul brute par core, tu comprends ce terme?
Je le repete, meme si j'ai peu d'espoir que tu l'accepte, il s'agit d'evaluer la puissance de traitement d'un core, pas de savoir si une unite specialisee avec une architecture parallele fait mieux qu'un core x86 ou si un DSP traite plus vite un signal qu'un core x86, ou si une unite dediee au chiffrement fait mieux qu'un core x86, ou si le niveau de pipeline et le scheduler arrivent a mettre 3 instructions (exécutées en parallele) par cycles,.... non, la question ici c'est quelle est la vitesse de traitement d'une fonction par le core!

Bien évidement si on monte la fréquence, on augmente mécaniquement la vitesse de traitement du flux d'instructions/donnees, c'est pourtant pas difficile a comprendre.
Ensuite mettre 3 instructions par cycles, c'est bien, mais ca a un cout lie a la complexité que cela implique derriere. Faut inclure dans le calcul tout le processus de pretraitement dans ce cas, rajouter le temps perdu lorsque la prediction echoue et qu'il faut relancer le calcul,etc... Par contre augmenter la fréquence de traitement, c'est simple (a calculer et a gérer) et efficace (sauf en terme de consommation, element tres en défaveur du x86 et de sa complication extreme).

Apres, pour rappel si la frequence nominale des Core 2 etaient sous-dimensionnee, c'est qu'Intel avait encore les moyens d'etre prudent sur leur fréquence de certification parce qu'Intel devait vraiment faire attention a l'epoque... la reputation de barbecue des x86 etait encore dans les esprits. Avec Haswell et plus encore Broadwell, les benefices sont si faibles qu'Intel n'a pas le choix et doit certifier des frequences qu'il n'aurait jamais fait 5 ans plus tot. Ce veut juste dire qu'Intel prend sur la capacite d'overclock, et rien d'autre. D'un autre cote Intel maitrisant l'overclock dynamique (ils appellent ca le mode turbo) tout comme d'underclocking (ils appellent ca l'optimisation énergétique...) et les cycles de vie des architectures etant toujours plus court, Intel ne prend pas un gros risque.

Si le passage aux 64bit a représente une pose dans cette course a la puissance, cela va repartir de plus belle maintenant.

Dans la réalité, on constate que cette pause ne semble pas liée au passage au 64 bits : chez Apple, le ralentissement des gains de performances intervient après le passage au 64 bits, chez les autres il intervient avant... Le point commun, c'est qu'il intervient chez tout le monde en même temps. De là à supposer que ça n'a rien à voir avec le 64 bits mais plutôt avec le fait qu'on commence à atteindre les limites de ce qu'on peut tirer d'un CPU qui doit rentrer dans un smartphone, il n'y a qu'un pas...

Alors je reformule vu que ca pas l'air d'etre clair pour toi.
Apple a preparé le passage au 64 bits depuis des années et a été trés en avance sur la concurrence pour commercialiser un processeur ARM64. Toute la concurrence a ete surprise et a du bouleverser son calendrier pour passer au 64bit, cela entrainant des retard et des difficultés qui ont de fait ralentie le travail pour assurer la montee en puissance des processeurs.
Apple ayant pris une avance suffisante, n'a fait qu'une petite optimisation de son A7 en travaillant surtout sur l'unite graphique. Le gros morceau c'est l'A9 et surtout l'A10 qui seront des processeurs devant tourner sur mobile et sur desktop. Et la on va pas parler de 20% de progression au detour d'une petite optimisation mais d'une montee en puissance pour du desktop. Et ne t'en fais pas pour la concurrence d'Apple, ils sont en train de passer l'obstacle du 64 bit et vont reprendre la course a la puissance, car eux aussi ils preparent des processeurs pour desktop.

Ceci étant, selon tes dires..., Intel serait passe au 64 bits facilement... mais qui a créé l'architecture 64 bits du x86,? Ah oui AMD avec la gamme AMD64, ca te rappelle quelque chose? Bon aujourd'hui Intel ose appeler ce jeu d'instructions et par extension l'architecture Intel 64...

Néanmoins, faut reconnaitre qu'Intel a fait des progrès extraordinaires sur l'unite graphique battant a ce niveau toutes les previsions (et probablement la conjecture de Moore).

Ce message a été modifié par r@net54 - 18 Jan 2015, 06:29.

[zero]

r@net54, tu confonds traitement, calcul et opération ! Tu confonds aussi fonction et instruction.

Ce message a été modifié par zero - 18 Jan 2015, 07:47.

[Ambroise]

r@net54, tu confonds traitement, calcul et opération ! Tu confonds aussi fonction et instruction.

Mon Dieu ! r@net54 n'est donc pas en train de troller sur le forum. Il croit réellement à ce qu'il avance !

[SartMatt]

Eh bien entendu le temps de calcul n'a strictement rien en commun avec la vitesse de calcul...
Au fait on mesure la vitesse, comment deja?

Bien sûr que c'est lié, je dis pas le contraire... Mais ça donne par contre des courbes qui n'ont pas du tout la même allure, comme le montre la courbe de vitesse de calcul que j'obtiens à partir des mêmes données que celles qui donnent ta courbe de temps de calcul...
Là où sur ta courbe on a l'impression qu'il n'y a plus aucune progression depuis 2005, la courbe de vitesse donne bien l'impression inverse... Avec strictement les mêmes données (je suis allé récupérer les chiffres sur HWBot).

Et comme face à ta courbe de temps de calcul des x86, tu mettais une courbe de vitesse de calcul des ARM Apple, le minimum de l'honnêteté intellectuelle pour rendre les deux visuellement comparables (c'est quand même le but des représentations graphiques...) aurait bien été qu'elles représentent la même chose, donc soit convertir la courbe des x86 en courbe de vitesse, soit convertir la courbe des ARM Apple en courbe de temps de calcul. Comme j'avais les données qui ont servi pour faire la courbe de temps de calcul des x86, c'était plus facile de faire avec précision la courbe de vitesse, donc je l'ai fait. Et si on faisait la courbe de temps de calcul des ARM Apple à partir de la courbe de vitesse donnée par Apple, on obtiendrait une courbe du même aspect que celle du temps de calcul des x86, c'est à dire une courbe qui s'écrase de plus en plus. N'importe qui qui a suivi correctement des cours de maths de première S devrait comprendre ça...

Tiens, pour illustrer, voici les courbes du temps de traitement et de la vitesse avec une croissance exponentielle des performances :


Avec ça, tu vas continuer à prétendre que comme vitesse et temps sont liés, représenter l'un ou l'autre ne change rien ?
De la première courbe, tu prétendrais qu'à partir de la septième itération, les performances stagnent... Alors qu'entre la septième et la dixième, les performances progressent d'un même facteur qu'entre la première et la quatrième (et dans l'absolu, progressent autant entre la 9ème et la 10ème qu'entre la 1ère et la 9ème...). Avec la seconde courbe, c'est flagrant qu'il n'y a pas stagnation.

Une courbe de temps de traitement donnera toujours l'impression de se tasser, sauf si un jour tu trouves une solution pour que le résultat du traitement arrive avant qu'on le demande (pour avoir un temps de traitement négatif...). Autrement, tu auras toujours une courbe qui tend asymptotiquement vers 0, et donne donc rapidement l'impression d'une stagnation, même si tu multiplies les performances par 100 chaque année (en fait, plus le facteur est grand, plus la courbe va sembler stagner rapidement...). Niveau première S.

Tu racontes n'importe quoi.
Que tu me denigres parce que mon argumentaire contredis tes croyances c'est une technique rethorique comme une autre, mais denigrer un programme comme super PI, ca va un peu loin.

Je ne dénigre pas Super PI. Je t'explique ce que c'est. Tiens, va voir Wikipedia : http://fr.wikipedia.org/wiki/Super_PI
"Super Pi n'est plus mis à jour depuis 1995, cependant il est toujours très utilisé surtout dans le milieu de l'overclocking." C'est juste exactement ce que j'ai dit (et ça confirme au passage mon doute sur le MMX, puisque le MMX est arrivé en 1997, deux ans après l'abandon de SuperPi) : ça n'utilise aucune instruction moderne, et ça ne profite pas des cœurs multiples. D'où le fait qu'à part s'amuser à faire des records, plus personne ne l'utilise (HWBot, qui est la soruce de ton graphique, c'est un site d'overclockers avec des bases de record).

Et cette phrase sur la page Wikipedia de Super PI remonte à 2008, c'est dire à quel point il est connu et ancien que Super PI est juste bon à faire des records, pas à évaluer les performances d'un CPU en usage réel.

En fait ce que tu es en train d'insinuer c'est que Super PI n'evalue pas l'efficacite des autres architectures (unitee vectoriel, coprocesseur,...) qui sont embarquées dans les SoC x86...

Je ne l'insinue pas. Je l'affirme : un programme qui date d'avant ces unités vectoriels ne peut pas les utiliser. Et ces unités ne sont pas "embarquées dans les SoC x86", mais bien dans les CPU x86. Elles font partie intégrante du cœur d'exécution du CPU, ce n'est pas un circuit externe accolé au CPU au sein d'un SoC.

Super PI est justement un des rares logiciel capables d'evaluer la puissance de calcul brute et lineaire d'un processeur. Il demontre un resultat comparable depuis des annees: la puissance de calcul brute d'un core!

Non. Uniquement la puissance de calcul brute avec les vieilles instructions, sans tenir compte des nouvelles.
Par contre, il y a du progrès, tu reconnais que ça ne tient pas compte des cœurs multiples, donc que ça n'est pas représentatif de la puissance réellement exploitable des processeurs... Donc tu sauras désormais qu'il ne faut pas comparer la courbe des résultats sous Super Pi à la courbe d'Apple qui prend en compte les cœurs multiples.

Tu peux comparer un processeur d'il y a 10 an avec un processeur actuel et avoir un resultat fiable.

Fiable, oui. Représentatif, non. Parce que contrairement à Super Pi, les applications ont évolué ces 20 dernières années. Elles utilisent massivement les nouvelles instructions qui ont été introduites ces 20 dernières années, et les applications gourmandes exploitent pour la plupart la multiplication des cœurs. Un test ne prenant en compte ni les nouvelles instructions, ni les cœurs supplémentaires n'est donc pas représentatif des performances obtenues en usage réel. C'est pour ça qu'il n'y a que les overclockers qui jouent encore à Super Pi, les tests comparatifs de CPU ne l'utilisent plus depuis longtemps.

Le fait que les x86 d'aujourdhui sont des SoC, n'est pas une mauvaise chose en soi, puisque ca permet de compenser les limites de d'une vielle architecture. Et heureusement que les unites vectorielles existent dans ces SoC, parce que sinon tout ce qui est traitement "multimedia" ne serait simplement pas possible.

Les unités MMX, SSE, AVX et cie font bien partie du CPU, ce ne sont pas des unités séparées couplées au CPU au sein du SoC ! À quelques exceptions près (les SoC Bay Trail et quelques SoC Core i pour ultrabooks), la seule unité de calcul externe qui soit intégrée dans les die des CPU Intel, c'est le GPU, et ce n'est pas de ça que je parlais quand je disais que SuperPi n'utilise aucune des unités de nouvelles unités de calcul qui sont massivement utilisées par les applications d'aujourd'hui.
Et la plupart des CPU Intel ne sont PAS de SoC. Ce sont simplement des CPU avec un contrôleur mémoire, un contrôleur PCI-E et un GPU dans le même die, ce n'est pas du tout le niveau d'intégration qu'on a avec un SoC (qui intègre également le réseau, les contrôleurs de stockage, les I/O, l'audio, souvent même le traitement de la sortie du capteur photo, etc...).

Le seul cas où le MMX est une unité externe par rapport au CPU (ou plutôt est vu comme une unité externe), c'est, comme l'a expliqué Ambroise plus haut, sur les Strong ARM d'Intel, où Intel n'a pas eu le droit d'intégrer directement le MMX dans le jeu d'instructions natif du CPU.

Donc tu peux denigrer ce programme parce qu'il derange tes croyances, en attendant ses resultats sont significatifs pour toute personne qui s'intéresse a la veritable puissance de calcul du core.

Donc les seules personnes qui s'intéresseraient encore à la véritable puissance de calcul du core, ce sont toi et les overclockeurs ?

Je le repete, meme si j'ai peu d'espoir que tu l'accepte, il s'agit d'evaluer la puissance de traitement d'un core

Alors pourquoi compares tu cette courbe à celle d'Apple qui prend bien évidemment les cœurs supplémentaires en compte ? Ah oui, parce que tu ne fais preuve d'aucune honnêteté intellectuelle.

Apple ayant pris une avance suffisante, n'a fait qu'une petite optimisation de son A7.

Ah ben oui, c'est bien connu. Quand on prend de l'avance et qu'on a des moyens colossaux pour continuer de financer la R&D, on préfère attendre la concurrence
Je croyais pourtant que les processeur ARM ont encore une énorme marge de progression super facile à exploiter ?

Le fait qu'Apple, qui ne suis pas trop la course aux cœurs pour se concentrer plutôt sur les performance par cœur, ait ajouté un troisième cœur sur l'iPad plutôt que de profiter de cette marge de progression si facile à exploiter sur la performance par cœur tendrait plutôt à montrer que cette marge n'existe que dans ton imagination, et que face aux difficultés à améliorer les performances de son cœur, Apple a préféré ajouter un cœur supplémentaire.

Ceci étant, selon tes dires..., Intel serait passe au 64 bits facilement... mais qui a créé l'architecture 64 bits du x86,? Ah oui AMD avec la gamme AMD64, ca te rappelle quelque chose? Bon aujourd'hui Intel ose appeler ce jeu d'instructions et par extension l'architecture Intel 64...

Oui, c'est AMD. Ça ne veut pas pour autant dire qu'Intel a eu des difficultés à faire passer le x86 au 64 bits (surtout que ce qu'ils ont repris d'AMD, c'est juste le jeu d'instruction... donc en fait essentiellement des variantes 64 bits des instructions 32 bits existantes, et le choix de l'opcode à attribuer à ces instructions... extrêmement complexe quoi ^^)... La raison pour laquelle c'est AMD qui a fait le x86-64 avant Intel est bien plus commerciale que technique : les plans d'Intel pour le 64 bits, c'était l'IA-64 (utilisé sur l'Itanium), qui devait par la suite être décliné dans des processeurs grand public. AMD, qui n'avait pas de licence IA-64 a préféré faire évoluer le x86 en 64 bits. Intel ayant compris que la complexité de l'IA-64 et l'arrivée du 64 bits en x86 allait l'empêcher d'amener l'IA-64 en dehors des datacenter, il a suivi AMD sur le x86-64. Mais il ne semble pas avoir rencontré de grosses difficultés à ce niveau, le premier CPU Intel x86-64 est arrivé peu de temps après les Athlon 64 (juin 2004 contre septembre 2003).

Si j'étais mauvaise langue, je dirais même que le fait qu'AMD ait été le premier à faire du x86-64 montre à quel point il n'y avait aucune difficulté à le faire... Parce que si AMD a pu le faire avec un tel succès (les Athlon 64, c'est la plus belle réussite d'AMD...) avec les moyens qu'il avait, c'est assez clair qu'Intel n'aurait eu aucune difficulté à le faire sans AMD s'il en avait pris la décision avant.

Et le fait est qu'aujourd'hui contrairement à ce que tu laissais entendre Intel n'a aucun travail à faire pour passer les Atom en 64 bits, ils le sont depuis des années.

[Ambroise]

Ceci étant, selon tes dires..., Intel serait passe au 64 bits facilement... mais qui a créé l'architecture 64 bits du x86,? Ah oui AMD avec la gamme AMD64, ca te rappelle quelque chose? Bon aujourd'hui Intel ose appeler ce jeu d'instructions et par extension l'architecture Intel 64...

Intel a accepté d'utiliser un jeu d'instruction 64 bits compatible avec celui d'AMD : c'était plutôt une preuve de bonne volonté. Ils auraient pu imposer leur propre version en profitant de leur position dominante.
Et quand aux difficultés qu'ils auraient éprouvé pour rattraper leur retard sur AMD ? leur premier processeur x86 64 bits est sorti 6 mois après le K8... Visiblement ils étaient à l'aise sur la question.

[Tophe974]

Encore une fois : oui, peut-être qu'il y a les deux dans le paquet, mais ça n'empêche pas qu'il y a quand même un mec à la base qui a été obligé de coder pour deux architectures différentes. Ce n'est pas parce que tu codes un truc pour un processeur ARM que magiquement ton compilateur te sort une version x86 à côté.
C'est comme si j'offre un CD et un livre à ma petite cousine, je peux très bien faire un seul paquet global donc un seul cadeau, ça ne m'empêcheras pas d'avoir à acheter les deux séparément !

C'est bien pour ça qu'on code avec un langage "haut niveau" et pas en assembleur : ton même source en C peut tout à fait compiler pour ppc, ppc64, x86, x64, arm et arm64.
Il y a bien sur quelques règles à respecter, mais en utilisant les frameworks d'aujourd'hui, le surcoût en développement est nul ! (je ne parle pas des tests ici).
Si on regarde le passage en 64bits sur iPhone, il n'a posé aucun problème majeur.
Il n'y a guère que les personnes qui injectent du code assembleur qui ont eu du boulot ; mais ça, ils le savaient dès le début.
Pour 99% des applications, pas 1 seule ligne d'asm est nécessaire.
Le 1% restant ? je peux découper le besoin en 2 :
- ceux qui le font pour la beauté
- ceux qui en ont vraiment besoin : ces personnes auraient de toutes façons retravaillé leur soft pour profiter de la nouvelle architecture processeur disponible

Intel a accepté d'utiliser un jeu d'instruction 64 bits compatible avec celui d'AMD : c'était plutôt une preuve de bonne volonté. Ils auraient pu imposer leur propre version en profitant de leur position dominante.
Et quand aux difficultés qu'ils auraient éprouvé pour rattraper leur retard sur AMD ? leur premier processeur x86 64 bits est sorti 6 mois après le K8... Visiblement ils étaient à l'aise sur la question.

C'est surtout Microsoft qui a imposé son choix à Intel, en leur expliquant :
- qu'ils avaient déjà fait un portage vers Itanium, et que les performances pour le grand publique n'étaient pas convaincantes
- qu'ils avaient déjà fait un autre portage 64 bits vers l'archi AMD64 (maintenant nommée x86_64)
- qu'ils n'allaient pas refaire un 3è portage 64 bits vers une nouvelle extension x86 64 bits.

[Licorne31]

Et pourquoi pas un retour au PPC, avec le Power8 qui enrhume le X86?

http://www.itjungle.com/tfh/tfh092914-story02.html

(je sais, je rêve...)

[Ambroise]

C'est surtout Microsoft qui a imposé son choix à Intel, en leur expliquant :
- qu'ils avaient déjà fait un portage vers Itanium, et que les performances pour le grand publique n'étaient pas convaincantes
- qu'ils avaient déjà fait un autre portage 64 bits vers l'archi AMD64 (maintenant nommée x86_64)
- qu'ils n'allaient pas refaire un 3è portage 64 bits vers une nouvelle extension x86 64 bits.

Microsoft a bien annoncé qu'ils ne souhaitaient pas développer deux versions 64 bits de Windows x86 et on les comprend. Mais ils n'ont rien imposé à Intel (et il n'aurait pas pu le faire quoi qu'il en soit : si Intel avait sorti sa propre version 64 bits les processeurs Intel auraient continuer à faire 90% des ventes quoi qu'il en soit et la version d'Intel se serait imposée d'elle-même).
Intel a décidé d'être (à peu près) compatible avec l'architecture présentée par AMD dès le lancement du projet Yamhill en 2001, soit 4 ans avant la sortie de la version x64 de Windows XP Pro. Et le premier processeur x86 64 bits d'Intel est sorti près d'un an avant la présentation de Windows XP Pro x64.

Pour moi la raison principale qui a conduit Intel à rester compatible avec AMD c'était avant tout que l'implémentation d'AMD était intelligente et correspondait en grande partie aux extensions 64 bits possibles dont Intel avait déjà parlé dix ans auparavant. S'ils avaient choisi leur propre architecture, ils auraient de plus pris le risque d'un procès pour abus de position dominante. Mais l'influence de Microsoft n'a à mon avis pu n'être que marginale. Ils auraient pu au pire faire leur mauvaise tête en ne livrant que des versions OEM limitées à AMD de Windows XP Pro x64 entre 2005 et 2007: mais dès la sortie de NT 6.0 (Vista) en 2007 ils seraient revenus à la crèmerie Intel pour être compatibles avec les millions de processeurs x86 vendus entre temps.

[Ambroise]

Et pourquoi pas un retour au PPC, avec le Power8 qui enrhume le X86?

http://www.itjungle.com/tfh/tfh092914-story02.html

(je sais, je rêve...)

Cela paraît trop tard hélas mais moi aussi ça me fait rêver.

A l'époque du passage au x86, j'avais vraiment espéré qu'Apple continuerait à faire du haut de gamme Mac Pro avec des IBM Power. Je pense que ça doit faire la 4ème fois en 10 ans qu'une nouvelle génération d'IBM Power dépasse largement en puissance le plus puissant des x86 (en pratique ça n'est que temporaire, Intel et IBM n'arrêtent pas de se redépasser l'un, l'autre même si je trouve que globalement c'est le Power qui laisse la plus forte impression de puissance) et donc ça aurait donné au Mac Pro une belle image de machine d'exception.

Et on sait tous qu'Apple aurait largement eu les moyens de financer cela (mais ça n'était pas du tout clair à l'époque...).

Aujourd'hui il y a aurait dans le catalogue d'Apple un MacPro Power7+ à 4,35Ghz qui serait qualifié de petite bombe. Et il y aurait à côté un monstre à 4 Power8 et 48 coeurs et qui serait annoncé comme digne de la catégorie supercalculateur.