Connexion
Abonnez-vous

Comparatif des SoC Apple : des M1 aux M4, M4 Pro et M4 Max

Attention, M6 est déjà pris !

Comparatif des SoC Apple : des M1 aux M4, M4 Pro et M4 Max

Comment se positionne la nouvelle puce M4 Pro d’Apple face à la M4 ? Et qu’en est-il de la M4 Max face à la M4 Pro et la M4 ? Nous avons regroupé les principales caractéristiques techniques dans un tableau pour vous aider à y voir plus clair.

Le 30 octobre à 17h55

Cette semaine, Apple a présenté deux nouvelles puces : la M4 Pro inaugurée avec les Mac mini hier, et la M4 Max lancée aujourd’hui avec les nouveaux MacBook Pro. Voilà de quoi compléter la famille des M4 présentée pour la première fois en mai de cette année dans l'iPad Pro.

Notre comparatif de 12 SoC « M »

Nous avons regroupé l’ensemble des caractéristiques techniques des nouveaux SoC dans un tableau comparatif, avec les différentes déclinaisons des M1, M2 et M3 à titre de comparaison :

Nombre de cœurs (CPU et GPU) et mémoire unifiée variables

Comme toujours chez Apple, une même puce peut avoir plusieurs variantes. En M4 par exemple, la partie CPU intègre 8 à 10 cœurs, contre 12 ou 14 pour la version Pro et 14 ou 16 pour le M4 Max. Attention donc au moment de choisir le SoC de votre machine.

La puce M4 reste assez proche de la M3 avec trois ou quatre cœurs performances. Par contre la version Pro s’approche davantage du M4 Max avec 8 à 10 cœurs performances, là où le M3 Pro en avait cinq ou six.

Même chose sur la partie GPU, avec là encore des écarts sur les performances. Le nombre de cœurs du NPU pour les calculs liés à l’intelligence artificielle ainsi que les performances semblent être les mêmes sur l’ensemble des SoC M4, comme c’était le cas avec les générations précédentes.

« Intégrant un Neural Engine jusqu’à deux fois plus rapide que celui de la génération précédente et des accélérateurs d’apprentissage automatique améliorés dans les CPU, les puces de la famille M4 livrent des performances incroyables pour l’exécution de projets professionnels exigeants et de tâches exploitant l’IA », affirme Apple… sans s’étendre davantage sur les chiffres, comme lors du lancement du M4.

Si Apple est passé à 16 Go de mémoire minimum sur ses nouveaux produits (enfin…), la quantité maximale dépend aussi du SoC : 32 Go en M4, 64 Go en M4 Pro et enfin 128 Go en M4 Pro Max. La mémoire n’est pour rappel pas évolutive une fois la machine achetée.

Et encore, c’est la théorie. En pratique, c'est plus compliqué. Sur la fiche produit des nouveaux MacBook Pro, Apple annonce les limitations suivantes : 36 Go de mémoire unifiée sur les M4 Max avec CPU 14 cœurs, 24 ou 48 Go sur les M4 Pro avec CPU 16 cœurs, et enfin jusqu'à 128 Go uniquement avec les M4 Max à 16 cœurs. Une limite qui dépend donc à la fois de la variante du SoC, mais également de son nombre de cœurs. Un découpage beaucoup plus commercial que technique.

Thunderbolt 5, nombre de moteurs de codage et décodage

Toutes les puces M4 disposent d’une accélération matérielle pour H.264, HEVC, ProRes et ProRes RAW, ainsi que d’un moteur de décodage vidéo. La puce M4 Max juxtaposant deux GPU M4 Pro, elle hérite du double de ces moteurs : deux pour le codage, deux pour le codage/décodage ProRes. Le décodage AV1 est aussi supportée par l’ensemble des puces M4.

Signalons aussi que les puces M4 Pro et Max proposent du Thunderbolt 5 jusqu’à 120 Gb/s, là où la M4 classique se contente de Thunderbolt 4.

On vous épargne le discours sur les performances par rapport aux puces des générations précédentes. Il se trouve dans ce billet de blog.

Commentaires (20)

votre avatar
Wait. C'est moi ou le M3 Pro semble moins puissant que le M2 Pro (hors Neural Engine) ?
Au moins dans le tableau comparatif en tout cas.
votre avatar
Sans les fréquences des cœurs CPU/GPU tu peux rien comparer.

Le M3 Pro écrase (+20%) le M2 Pro sur les benchs "single core" et l'écart se resserre en multi (moins de cœurs mais plus rapides).
votre avatar
Ouais, entre temps, j'ai été fouiller un peu, et oui, la fréquence est plus haute sur le M3.
Mais le fait que le M2 ait plus de performance cores que le M3 et une plus grande bande passante mémoire font que dans certains usages, le M2 est plus rapide que le M3.
La baisse du nombre de transistors est un bon indicateur de la baisse de puissance également, mais ici, vu l'ordre de grandeur, ça joue pas à grand chose.

Bref, tout ça pour dire que c'est fou de sortir un processeur moins bon sur les specs de base que son prédécesseur. Surtout sur la bande passante mémoire. Je comprend pas comment on peut sortir un produit comme ça. Mais bon, c'est Apple, faut pas chercher à comprendre…

(note, tous les "MX" sont des "MX Pro". Flemme de l'écrire à chaque fois).
votre avatar
Dommage que les 128GB de RAM soient réservés à LA plus grosse puce hors de prix. Surtout que le M4, M4 Pro et M4 Max ont le même NPU.
votre avatar
C’est vrai d’un certain côté. Néanmoins pas tant que ça : quand on a besoin de 128Gb de mémoire unifiée - sur un laptop rappelons le - on peut estimer qu’on ne mégote plus sur le reste des critères en matière de performances et que le choix de la puce la plus puissante est je pense une sorte d’évidence.
votre avatar
Est-ce qu'Apple a communiqué sur les détails du back-end de leur CPU ?
votre avatar
"C'est un back-end Apple top moumoute encore mieux que le précédent :fumer: "

Tu voulais quel genre de com de leur part ?
Apple communique rarement sur la partie matériel, c'est "accessoire", le plus important c'est l'expérience utilisateur.
votre avatar
De mémoire Apple avait communiqué sur son archi pour les M1. Et comme ils développent leur propre puce, ils pourraient avoir des slides similaires à Intel et AMD histoire de jouer "qui à la plus grosse" (ils aiment ça les Ricains) ou bien de dire "Venez chez nous, l'x86 c'est pour les vieux".
votre avatar
C'était assez superficiel quand même pour le M1.

Et les concours de com de Intel et AMD ne servent qu'à une partie des clients, une autre partie d'en moque. Cela contribue même à l'impression d'ultracomplexité de l'informatique. Plus on a d'infos, plus on a de comparaisons à faire, plus il y a de doutes...

Un peu comme vendre une voiture de série en indiquant jusqu'au 0 à 100 par défaut...
votre avatar
ça dépend de tes usages. De mémoire, les benchmarks génériques n'étaient pas forcément les plus impressionnants. Par contre, dès que tu passes en calculs flottants, le M1 était quand même impressionnant à son époque. Mais c'est quand même un usage assez spécifique je te l'accorde.

Je me sers pas de la com' de ces boîtes. Mais ce qui m’intéresse c'est les détails plus profonds comme l'IPC, la longueur du décodeur d'instruction, le TLB, l'organisation des unités flottantes, la longeur du data path.... Et c'est pour ça que je préfère les slides car ces informations sont parfois accessibles. Et je chérie ces informations car avec tu peux comprendre ce qui se passe dans le CPU mieux que les slides des marketeux sur les perfs du CPU lors de benchmark (dont on ne connait jamais les conditions de tests [OS, température ambiante...])

En ce qui concerne l'ultracomplexicité de l'informatique... Et bien oui l'informatique est une science et c'est très complexe. Rien de nouveaux sous le Soleil. Par contre, la quantité d'informations n'est pas un problème tant que ce n'est pas du bullshit de marketeux (parce que ça c'est vraiment cancérigène).
Après, c'est à chacun de savoir ce qu'il intéresse dans les infos et ce qu'il considère comme utile à garder ou à ignorer pour son analyse. Ce n'est, cependant, pas propre à l'informatique ou même spécifique à ces histoires d'architectures CPU.
votre avatar
"c'est les détails plus profonds comme l'IPC, la longueur du décodeur d'instruction, le TLB, l'organisation des unités flottantes, la longeur du data path"

Autant ce sont des informations précieuses quand on fait des compilateurs CPU, autant sur des machines ultra hétérogènes et des traitements répartis comme maintenant, ça a peu d'intérêt je trouve, sans compter que l'IPC ARM et l'IPC x64 sont non comparables, surtout si on parle d'IPC de type AVX ou autre.

Ce qui m'intéresserait, c'est de voir comment les Apple Mx réorganisent les instructions. Je penche depuis le début pour une réorganisation qui tant vers une exécution proche du VLIW, ce qui expliquerait en grande partie les perfs en émulation.

Mais c'est du pinaillage: si je développais des compilateurs ça m'intéresserait, mais pour de l'utilisation, ce qui m'intéresse c'est plus le confort (qui n'est pas totalement /uniquement lié aux perfs théorique d'un CPU)
votre avatar
Ça l'intéresse professionnellement. Elle bosse autour des supercalculateurs, du calcul numérique.
Bref, elle recherche des infos qui ne sont pas utiles pour le commun des mortels.

Ses commentaires sur le sujet sont généralement très intéressants.
votre avatar
"Autant ce sont des informations précieuses quand on fait des compilateurs CPU, autant sur des machines ultra hétérogènes et des traitements répartis comme maintenant, ça a peu d'intérêt je trouve, sans compter que l'IPC ARM et l'IPC x64 sont non comparables, surtout si on parle d'IPC de type AVX ou autre."

Tu es dans le vrai pour le compilateur. En revanche je ne suis pas en total accord pour la suite. Certaines de ces informations sont pertinentes pour des cas d'usages. Le TLB a une énorme importance pour les accès mémoires, sa profondeur et la taille des pages peut avoir une influence non-négligeable sur certains scénarios mais connaître aussi le nombre d'unités FPU sont des détails importants. Pas uniquement pour les compilateurs ou des applications spécifiques, mais aussi pour voir l'évolution d'une architecture et éviter le discours marketing.

Même si ton architecture est très hétérogènes au sein de ta puce (CPU, NPU, GPU...) il n'empêche que c'est intéressant en soi d'avoir les informations propres à chaque partie et à leur interconnexion, indépendamment du fait que tu réalises plus de calculs d'un type que d'un autres.

Bonne question pour VLIW, je ne sais pas pour le CPU. Par contre pour le GPU et le DSP c'est plus que probable car c'est plutôt répandu.

*
"Mais c'est du pinaillage: si je développais des compilateurs ça m'intéresserait, mais pour de l'utilisation, ce qui m'intéresse c'est plus le confort (qui n'est pas totalement /uniquement lié aux perfs théorique d'un CPU)"*

Et moi ce qui m'intéresse, au delà du confort, c'est d'avoir un processeur adapté à mon usage. Si je dois acheter (ou louer) ce type de machine, j'aime savoir ce qu'il y a dedans à minima pour faire un choix éclairé.

Après je tiens à préciser: Mme Michu & co n'ont clairement rien à faire de ceci. La notion même de fréquence ou de coeur de calculs sont très loin dans leur critère d'achat. Elles préfèrent des arguments plus "marketing" que techniques. Et sur ce point, elles achèteront Apple pour ce qu'Apple représente et non ce qu'Apple a mis comme génie dans la puce.
votre avatar
Je comprends bien l'attente.

Apple ne fait plus dans le pro (dans le sens ils ont tué leurs serveurs, leurs téléphones et ordis sont une plaie en réseau encore maintenant).
Ils sont dans la station de travail et très orientés multi-média.
Pour le moment, ils glânent les clients du côté "ras le bol du blabla technique - on veut du résultat" (et je les comprends après 40 ans de "révolutions")

Apple a peut-être de l'or dans les mains, mais ne sautent pas encore le pas pour repartir sur le côté "technique". Pour le détail, peut-être un oeil du côté des forum de Avahi Linux donnera un peu d'idées?

Par contre à part usage extrêmement spécifique, en général il y a beaucoup à faire pour optimiser "aux petits oignons" pour sa machine, que ce soit sur l'algo, la répartition sur els coeurs, le type de parallélisation, la complexité des tâches ... Là on est en présence de CPU+RAM très rapides, ça aide à ne plus se poser trop de questions :)
votre avatar
Petit complément pour illustrer un peu la situation actuelle, où le CISC (et cela touche aussi ARM avec les différentes extensions d'ISA) reste difficile à mettre en place dans les compilo: x.com Twitter

(en espérant que ce x94 en perf n'équivaut pas à générer un film en noir et blanc :) )
votre avatar
Sympa, Peux-tu m'expliquer le lien entre CISC, la difficulté du compilo et les x97 de perf ? Je n'arrive pas à saisir ton point.
votre avatar
Actuellement les cpu sont une jungle. Les ISA sont pleines d'extensions, certaines remplaçant les autres, d'autres à mi-chemin d'être un NPU.
Mais les langages 'classiques' sont incapables de gérer correctement ces instructions. C'était d'ailleurs le constat dans les années 80 qui a amené le RISC et les 1er ARM: l'adoption de compilos haut niveau faisait disparaître l'usage des instructions cisc (par exemple, un x86 a des instructions de calcul en mode quasi texte ou de recherche qui ne correspondent à rien dans les langages).

Bref, je te donne raison sur l'intérêt de bien connaître son archi.

En même temps ces annonces ARM me rappellebt les années 90 quand IBM/Apple faisaient du Power PC (et les difficultés d'IBM à sortir le meilleur des power pc - ainsi que la difficulté de prédire comment allait se comporter le cpu ce qui gênait les dev en assembleur).

Bref, même si Apple a un excellent CPU, je n'enterrerait pas le x86 avant un moment. (Tout en remerciant AMD de montrer à Intel comment implémenter AVX512)
votre avatar
Oui les ISA sont devenus assez bordéliques, et je pense qu'une partie provient de la complexité croissante des processeurs qui deviennent de plus en plus "diversifié". Une autre partie provient des ballons d'essais, d'évolution (unités vectoriels passant de 128 -> 256 bits), de choix marketing...

Néanmoins tout les processeurs sont des risc à l'heure actuelle si on regarde dans les détails. Les x86 sont certes des CISC, mais dès le tout début du front-end du CPU, tu as une conversion des instructions en micro-opérations, qui ressemble furieusement à ce que tu as en risc. Est-ce une bonne chose ? Honnêtement je ne sais pas à l'heure actuelle. Les deux approches ont des avantages et inconvénients.

Mais néanmoins je pense que ce n'est pas nécessairement un problème de langage. Il existe un langage pour ça, et c'est l'assembleur. Les langages de haut-niveau s'appuie dessu via un interpréteur (compilateur, JIT...).
Je pense que le soucis concerne la capacité du compilateur a comprendre un code ou une fonction dans sa globalité et comment l'optimiser avec les bonnes instructions. Il y a, selon moi, une responsabilité majeure des développeurs qui, pour la très grande majorité, ignore comment fonctionne un ordinateur, et par conséquent n'ont pas connaissance de ce genre de détails et son impact.
Mais finalement, bien que non-idéal, on s'y retrouve sous la le bon outils pour la bonne tâche.
VLC est en majorité codé en C++, et tu trouves de l'assembleur pour les fonctions les plus critiques (e.g., en/decoders).

Je n'ai malheureusement jamais joué avec l'architecture PowerPC :( Mais je ne perds pas espoir avec la possiblité d'en louer ou d'en acheter un). En revanche, de ce que j'ai vu de son fonctionnement, elle a des trucs sympathiques.

Je te rejoins à 100%, l'x86 n'est pas mort ni à court ou moyen terme. Et oui, merci à AMD pour le double pumping qui ouvre la voie à de possibles folies (AVX-2048 ? :fume:). Apple ouvre une voix pour le particulier, mais c'est aussi la face visible d'un iceberg (Graviton, Ampère, Axion...).
votre avatar
Je vais conclure là-dessus:
- tout à fait d'accord, RISC ou cisc, ce n'est qu'une façade. Et même RISC-V n'est qu'un ensemble d'ISA, l'implémentation 'hardwired' d'un RISC-V est possible, mais ne permet pas les performances d'un CPU qui redécoupe/réorganise
- en termes de langages, je connais fortran et ses extensions (MPI/OpenMP) que j'ai utilisé il y a plus de 20 ans sur du code matriciel et 64 CPU. Je n'ai pas compris que fortran ne soit pas utilisé avec le GPGPU et le SIMD.
- pour les dev, c'est très variables. Mais j'estime que dans les outils bureautiques/internet, les CPU sont sollicités essentiellement pour de la comparaison de chaîne (indexation des colonnes, des attributs par nom, interprétation de scripts, de XML, de HTML...) +le chiffrement (donc multiplication et division entières). Tout soft de compta utilise une représentation parfaite des nombres (donc pas de virgule flottante) et ces opérations n'ont pas de bench généralement (bon, un peu avec les benchs bdd). Donc se poser la question de comment ma structure va tomber avec les pages mémoire ou si mes nombres sont alignés et si ma boucle passe en cache... C'est loin de 90% des dev.
- est-ce que les Apple M ne ressembleraient pas un peu aux transmeta?
votre avatar
Je rebondis juste sur la partie Fortran car pour le reste je suis ok, et pour le coup on a une expérience assez proche dessus (peut-être pas en durée d'années, par contre).

Fortran fait du SIMD mais il délègue ceci aux compilateurs. Tu le peux faire un peu plus "nativement" via l'iso_c_binding sur les intrinsiques. Note que le C++ propose d'introduire le SIMD dans la norme C++26. A ma connaissance actuelle, seul Rust propose de faire du SIMD d'une façon naturelle.
Dans tout les cas, il faut checker l'assembleur et parfois jouer avec les options du compilateurs et le code pour arriver à ses désirs.

Pour le GPGPU, tu peux regarder du coté d'OpenMP pour les calculs hétérogènes ou OpenACC. Certains compilateurs comme pg ce sont aussi associées avec Nvidia pour intégrer du CUDA en Fortran sous forme d'extension.

Comparatif des SoC Apple : des M1 aux M4, M4 Pro et M4 Max

  • Notre comparatif de 12 SoC « M »

  • Nombre de cœurs (CPU et GPU) et mémoire unifiée variables

  • Thunderbolt 5, nombre de moteurs de codage et décodage

Fermer