Où l'on reparle de Mac faisant l'impasse sur Intel, Réactions à la publication du 03/04/2018

[Ambroise]

Le plus amusant c'est qu'historiquement, la première CPU ARM était une puce Desktop, qui avait comme caractéristique d'être moins chère, consommant moins et plus performante que les CPU Intel concurrente. La preuve est donc faite, depuis la première CPU ARM
l'ARM2 de 1986 débitait 4 MIPS à 8Mhz, l'Intel i386DX seulement 2.15Mips à 16Mhz (et réussissait à le rattraper en tournant à 33Mhz! lol)

Il faudrait comparer des choses comparables, l'ARM2 était un jouet face au 386 : 2,15Mips pour un i386DX16 ça correspond à des Dhrystones VAX Mips. Soit un ensemble de programmes manipulant des entiers et faisant des calculs entiers.
4Mips pour un ARM2 tels que communiqués par ARM ça correspond au débit maximal d'opérations entières, la plus complexe de ces instructions étant l'addition sans retenue (l'ARM2 n'avait même pas de multiplication).
Si on compare un million d'addition sans retenue sur un ARM2 à un million de divisions sur un i386DX, l'ARM2 a des chances de mettre moins de cycles d'horloge : la division est une opération complexe qui demande beaucoup plus de ressources.
un i386DX16 dépassait largement les 4Mips sur des additions.

L'ARM2 était un tour de force impressionnant, développé par une micro-équipe face aux énormes moyens d'Intel. Mais il jouait dans une autre cours (celle des ordinateurs familiaux). le 386 face à ça offrait une gestion des domaines de privilèges (pour de véritables OS), de la virtualisation, le support des modes compatibles 16 bits, des registres matériels de débogage, des points d'arrêts matériels, un pipeline dimensionné pour permettre de tourner à 33Mhz...

[iAPX]

Le plus amusant c'est qu'historiquement, la première CPU ARM était une puce Desktop, qui avait comme caractéristique d'être moins chère, consommant moins et plus performante que les CPU Intel concurrente. La preuve est donc faite, depuis la première CPU ARM
l'ARM2 de 1986 débitait 4 MIPS à 8Mhz, l'Intel i386DX seulement 2.15Mips à 16Mhz (et réussissait à le rattraper en tournant à 33Mhz! lol)

Il faudrait comparer des choses comparables, l'ARM2 était un jouet face au 386 : 2,15Mips pour un i386DX16 ça correspond à des Dhrystones VAX Mips. Soit un ensemble de programmes manipulant des entiers et faisant des calculs entiers.
4Mips pour un ARM2 tels que communiqués par ARM ça correspond au débit maximal d'opérations entières, la plus complexe de ces instructions étant l'addition sans retenue (l'ARM2 n'avait même pas de multiplication).
Si on compare un million d'addition sans retenue sur un ARM2 à un million de divisions sur un i386DX, l'ARM2 a des chances de mettre moins de cycles d'horloge : la division est une opération complexe qui demande beaucoup plus de ressources.
un i386DX16 dépassait largement les 4Mips sur des additions.

L'ARM2 était un tour de force impressionnant, développé par une micro-équipe face aux énormes moyens d'Intel. Mais il jouait dans une autre cours (celle des ordinateurs familiaux). le 386 face à ça offrait une gestion des domaines de privilèges (pour de véritables OS), de la virtualisation, le support des modes compatibles 16 bits, des registres matériels de débogage, des points d'arrêts matériels, un pipeline dimensionné pour permettre de tourner à 33Mhz...

Dans les deux cas on parle de MIPS Dhrystone, la référence est ici sur wikipedia. Pour les mal-comprenant, dans le tableau c'est spécifié quand ce ne sont pas des Mips Dhrystone donc équivalents.
Un ARM2 à 8Mhz était presque aussi puissant qu'un iAPX 386 (eh oui! iAPX!) à 33Mhz sorti 3ans plus tard (si si!!!), pour une fraction du prix de l'iAPX 386 16Mhz.
"Il y a 30 ans l'Archimedes et son ARM2 donnait des leçons de puissance de calcul aux PC à base d'i386 et tout le monde était d'accord pour dire que c'était le début de la fin du x86." - @Ambroise, 11 décembre 2017

Merci et au revoir (pour les détails que tu évoques on peut en discuter mais tu vas pas aimer, j'ai vécu cette époque et j'ai des magazine Byte en PDF comme référence)

On est donc d'accord pour ceux qui parlent d'histoire, l'ARM2 a battu a plate couture le iAPX 386 (ou 80386 ou i386 ou 386DX, toujours du PR quand on est loser...), entres autres en exécutant 16 M ips en entier par seconde (2/cycle), comme un iAX 386 à 33Mhz (0.5/cycle, ouch!), donc en terme de performance/fréquence, performance/watt, performance/dollar. C'est encore actuellement le cas avec les Ax d'Apple avec un iPhone 8 2.3Ghz battant un MB Pr 13" 3.1Ghz...
Pour ceux qui veulent penser en terme "historique", je suis d'accord avec ça, donc ARM est meilleur pour eux

PS: la prochaine attaque va probablement être de comparer une mauvaise architecture sur base de jeu d'instruction ARM (pas une Apple , une bas-de-gamme Android), à l'équivalent Intel. De préférence avec un test geekbench 4 x86 émulé sur ARM pour "prouver" que c'est trop lent, entre l'émulation inutile et l'utilisation d'un SoC médiocre face aux puces Apple Ax (et le savoir-faire Apple en émulation). Keep reading...

Ce message a été modifié par iAPX - 6 Apr 2018, 11:35.

[Ambroise]

Dans les deux cas on parle de MIPS Dhrystone, la référence est ici sur wikipedia. Pour les mal-comprenant, dans le tableau c'est spécifié quand ce ne sont pas des Mips Dhrystone donc équivalents.
Un ARM2 à 8Mhz était presque aussi puissant qu'un iAPX 386 (eh oui! iAPX!) à 33Mhz sorti 3ans plus tard (si si!!!), pour une fraction du prix de l'iAPX 386 16Mhz.

C'est juste faux ! Et je trouve cela perturbant d'asséner des contre-vérités dans une discussion, cela coupe l'envie d'argumenter : les 0,5 Mips par Mhz sont des mesures nominales et dans le tableau la ligne ARM2 est dépourvue de référence contrairement aux autres lignes qui ont des renvois vers des DMIPS.
Cette page https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures reprend le chiffre de 4Mips et y ajoute le Dhrystone avec 0,33 DMIPS/Mhz.

Et pour produire des scores DMIPS acceptables il fallait écrire à la main en assembleur un équivalent du test dhrystone vues les difficultés que les compilateurs avaient à tirer des perfs des ARM2.
2,66 DMIPS c'était vraiment une super performance mais ça restait loin du 386 et surtout cela restait théorique faute de compilateur efficace.

[Guest_CPascal_*]

[quote name='raoulito' date='5 Apr 2018, 13:11' post='4204297']

le pb n’est pas le proce lui même, s'il fait la même chose je n'ai pas d’actions chez intel hélas mais si on a un pc fermé a mort avec un parc logiciel à foutre à la poubelle tout racheter avec bien sur du soft mono-plateforme non

apple retombe dans ses pires travers
plus les années passent plus c'est fermé alors qu'avec les mac retour de SJ on avait des macs permettant de mettre du win du linux etc sans soucis.sans compter avec la peau de banane du imac pro à 11K déjà obsolète, merci bien. vis à vis de apple sous Jobs j'avais confiance à 100% en eux > 0% et de leur seul fait depuis 2012. C'en est trop. payer 3X le prix du marché pour être en difficulté perpétuelle... non merci. mêmes causes mêmes effets vis à vis de Microsoft

> Debian
même pas Ubuntu
> Debian et mes 2 Macs vont y passer aussi
c'est si rapide si simple si fluide. la paix retrouvée quoi, celle que j'avais à l'époque de jobs.

Ce message a été modifié par CPascal - 7 Apr 2018, 10:03.

[Pixelux]

Pour avoir la paix. Il n'y a pas à dire Debian c'est un bon choix car c'est extrêmement stable.

Ça fait longtemps que tu connais Linux ?

[Ambroise]

"Il y a 30 ans l'Archimedes et son ARM2 donnait des leçons de puissance de calcul aux PC à base d'i386 et tout le monde était d'accord pour dire que c'était le début de la fin du x86." - @Ambroise, 11 décembre 2017

Merci et au revoir (pour les détails que tu évoques on peut en discuter mais tu vas pas aimer, j'ai vécu cette époque et j'ai des magazine Byte en PDF comme référence)

Je ne pensais pas que l'ironie de ma phrase était si peu perceptible. Byte a été effectivement un parfait exemple de cette tendance à encenser des ARM2 qui auraient donné des leçons de puissance aux 386. A l'époque ils présentaient de magnifiques courbes de croissance montrant la future évolution à la hausse quasi verticale de la puissance des RISC face à la stagnation inévitable de celles des CISC. Cela semblait évident à tout le monde à l'époque (et moi le premier). Mais tout le monde s'est trompé. Les seuls processeurs RISC qui ont survécu sont ceux qui ont fait le choix de l'adoption des principes du CISC (jeux d'instructions à taille variable, ajout de jeux d'instructions supplémentaires via des préfixes ou des ids de coprocesseurs, traduction du jeu d'instruction externe en instructions internes efficaces).

Et au finale les x86 sont passés de processeurs moyens en 1987 (avec une puissance plusieurs fois inférieure aux calculateurs de l'époque), aux processeurs les plus puissants sur les 15 dernières années et ce quel que soit le type de tâches : que ce soit en IPC, en mips, en mips par coeur ou en gflops, il n'y a plus aucune autre archi de CPU capable de s'approcher des perfs des x86.


Les premiers ARM2 commercialisés en 1987 permettaient d'afficher dans des applications de niche des scores comparables aux versions d'entrée de gamme des i386 de 1985. Et ces applications concernaient essentiellement le marché des ordinateurs familiaux : par exemple les programmes écrits en Arthur Basic sur Archimedes rivalisaient voir battaient les programmes équivalents écrits en GWBasic sur un PC 386. Mais c'était lié à la traditionnelle bonne qualité du basic BBC et surtout au fait qu'Acorn avait consacré les ressources qu'il fallait pour optimiser manuellement leur interpréteur Basic. Et sur le reste il n'y a jamais rien eu.

[Ambroise]

le pb n’est pas le proce lui même, s'il fait la même chose je n'ai pas d’actions chez intel hélas mais si on a un pc fermé a mort avec un parc logiciel à foutre à la poubelle tout racheter avec bien sur du soft mono-plateforme non

J'aimerai vraiment y croire à cette possibilité d'avoir des processeurs ARM qui font la même chose que ceux d'Intel mais ça fait plus de dix ans que j'entends que ce coup-ci c'est le cas : qu'on a trouvé un benchmark théorique qui montrerait la supériorité des architectures ARM... mais il n'y a jamais de concrétisation.

Je travaille sous MacOS, Ubuntu et Windows 10 sur processeur Intel x86, mais mes cibles sont en majeure partie des archis ARM (aussi bien de petits Cortex M pour du baremetal que de gros ARM pour du calcul intensif et parallèle). Je cherche depuis des années à travailler directement avec Linux sur ARM afin de gommer les différences matérielles entre mes tests unitaires et fonctionnels, et les applications cibles; mais il n'y a pas de solutions dans le commerce qui offrent une puissance acceptable. Et je ne vois ces solutions arriver à moyen terme.

A chaque fois qu'un constructeur lance sur le marché une même machine disponible en deux versions x86 et ARM, alors j'y cherche un espoir de voir les ARM égaler enfin les Intel. Mais ces espoirs sont toujours douchés par le fait que systématiquement il s'agit de comparer ce qui se fait de plus puissant chez ARM avec ce qui se fait de plus bridé chez Intel.

Samsung a sorti il y a quelques mois les Samsung Chromebook Plus et Pro. Les deux machines sont aussi belles qu'identiques. Elles fonctionnent quasiment dans les mêmes conditions (mêmes applications interprétées ou bytecodées) hormis lorsqu'elles font tourner des applications Android utilisant des librairies natives (les jeux) cas dans lesquels la version Pro avec son x86 doit exécuter une version non native (traduite) des libs.

Le proc ARM est plutôt impressionnant avec ses 6 coeurs à 2Ghz plus un septième Cortex M pour des tâches de contrôle à ultra basse consommation. Un processeur taillé pour les laptops avec un gros potentiel de calcul. Le Samsung Chromebook Pro a été conçu autour de ce processeur et un proto avec été présenté dès 2016 sous le nom Chromebook Pro OP1 avant que Samsung en fasse une déclinaison plus coûteuse avec un Intel core m3 de 6ème génération.

A l'usage il s'avère que la version ARM consomme davantage et a une plus faible autonomie que la version x86. Et comme on pouvait s'y attendre, la version x86 est sensiblement plus rapide que l'ARM. L'explication la plus probable pour la plus faible autonomie de l'ARM est qu'il passe nettement plus de temps à fréquence élevée compte tenu de sa faible puissance de calcul, ce qui l'amène à consommer beaucoup.

[CRISTOBOOL2]

Bonjour, franchement qu' Apple se lance dans une nouvelle transition ne m'étonnerais nullement, ils nous ont habitué aux stratégies incohérentes et à jouer la girouette sans arrêt leurs multiples erreurs stratégiques ont heureusement été compensées par les innovations multiples elles aussi, sans cela il y a belle lurette qu'Apple n'existerait plus.

Il y aura quand même trois écueils à une telle transition par rapport à la transition Intel:

premièrement en passant chez intel , la presse informatique a cessé son bashing systématique des macs, en passant sur ARM ce sera l'inverse...

deuxièmement en passant chez intel le consommateur moyen était rassuré et ils ont profité de l'image d'intel pour vendre leurs machines, en passant sur ARM ce sera l'inverse...

troisèmement en passant sur Intel, ils ont sortis bootcamp et la possibilité d'installer windows a énormément rassuré l'utilisateur moyen, en passant sur ARM ce sera l'inverse...

A mon avis ce sera beaucoup plus difficile comme transition.

Enfin pour la supposée supériorité des puces ARM d'apple sur les x86, je suis plus que dubitatif d'après les propos de certains ici on dirait qu'Apple fait aussi bien qu'intel avec 4 fois moins de transistors, il y a quand même des lois générales en matière de processeur il faut arrêter de croire au père noêl.

Apple n'est pas content d'intel ? s qu'ils passent sur AMD ! les rhyzen offrent une belle alternative, un mac pro 32 coeurs à 4 ghz ça aurait de la gueule non ?
ce serait pas plus simple ? mais bon comme on dit pourquoi faire simple quand on peut faire compliqué et puis avec Apple les erreurs stratégiques tout ça, ça fait partie de leur ADN ils n'en sont pas à leur coup d'essai !

edit: Pour avoir regardé ces histoires de bench entre puces ARM et puces Intel, attention tout de même ces tests sont très très limités non applicatifs et il semble bien que certains tirent partie des unités de calculs "pré-câblées" des puces ARM comme pour le décodage H265 qui sera comparé alors à des unités non pré-câblées sur la puce Intel+-SIMD.

Pour rappel un processeur "pré-câblé" est conçu pour faire un seul calcul et faire tourner un seul programme, il est donc limité à un seul usage mais a un énorme avantage de puissance par rapport à un processeur généraliste, ce dernier sera beaucoup plus lent mais pourra faire tourner tous les programmes que l'on veut.
Dans des machines telle que les smartphones et tablettes, les usages nécessitant de la puissance sont très peu nombreux et la limitation du TDP très forte, c'est donc tout à fait adapté de concevoir une petite puce généraliste au TDP très faible mais peu puissance en l'accompagnant d'unités de calculs spécifiques pour les quelques tâches lourdes demandées. Le premier exemple de puces spécifiques ce sont les GPU qui sont beaucoup plus puissants que les CPU mais nettement plus limités dans les usages.

Au contraire pour les ordinateurs les usages demandant beaucoup de puissance sont multiples, jeux vidéos, encodage, calculs scientifiques, traitement vidéo, photo, modélisation, cryptographie, bigdata ... On imagine pas faire une unité pré-câblée pour chaque usages comme dans ces puces ARM même si les GPU ou SIMD sont dans cette philosophie; qui plus est la limitation du TDP est bien moins forte on préférera alors une puces plus polyvalente que dans ces appareils mobiles.

Dans ce fil le vieux débat RISC contre CISC ressort mais il est totalement obsolète aujourd'hui, tous les x86 découpent leur instructions CISC en instructions RISC (depuis la fameuse architecture pentium) pour un prix en terme de nombre de transistors utilisés tout à fait négligeable aujourd'hui (pas du tout à l'époque du pentium ce qui a conféré un avantage au RISC pendant encore quelque années après). De plus tous les CPU actuels utilisent aussi des instructions que l'on peut qualifier de CISC comme dans les SIMD, ils sont tous hybrides car c'est le meilleur compromis qui a été trouvé.
.

Ce message a été modifié par CRISTOBOOL2 - 27 May 2018, 11:22.