Le test avec Geekbench, ça ne bench pas uniquement le CPU (sans considérer la RAM) ?
Oui je trouve aussi que la conclusion est un peu hâtive et que leurs tests ne prouvent pas grand-chose. D’ailleurs avec un cas d’usage où visiblement la quantité de données est plus élevée, la différence se fait sentir. Que le SOC Apple et les optimisations spécifiques de Big Sur apportent une gestion améliorée de la mémoire je veux bien le croire, en revanche si ton jeu de données est large, ça sera toujours plus rapide en RAM que d’aller le chercher sur le disque. Tant que ça rentre dans 8Go il n’y a pas de raison de voir une différence.
S’ils veulent vraiment faire des tests 8Go vs 16Go en termes de pertinence, ils doivent essayer de trouver des cas d’usage où le x86 se met à galérer avec 8Go et nous démontrer que la gestion de la mémoire du M1 permet d’aller plus loin avant de passer le point de rupture.
1 « J'aime »
Genre une centaine d’onglets sur firefox.
J’avoue qu’il manque des cas d’usage ou la RAM est vraiment nécéssaire
Fun fact : c’est comme ca que IBM a repoussé dans les cordes Google et la « suprématie quantique » a l’aide de la RAM de Summit 
32Go sur ma machine et je me sens souvent juste…
1 « J'aime »
3 Visual Studio en parallèle + Outlook + Firefox + Teams + TeamViewer → 25GB de RAM bouffé 
1 « J'aime »
Je vois pas du tout de quoi tu veux parler 
1 « J'aime »
Justement, sur ces chiffres, les M1 font largement mieux. Rien qu’Office ouvert c’est 6x moins de RAM bouffé en statique sur x86.
Forcément faut voir en usage avec un gros Raw toshop, etc. Mais par défaut, les apps ne consomment déjà plus autant « pour rien ».
En MAO, notamment avec les instruments et effets virtuels qui peuvent être très gourmands. Vu que c’est une partie sans doute non négligeable du marché Apple, ce serait intéressant de faire tourner des grosses usines comme Omnisphere 2 ou les VST orchestraux/acoustiques pour voir si leurs 8 Go s’avèrent suffisant.
1 « J'aime »
(Je suis pas spécialiste donc je dis peut être des conneries)
La gestion de la RAM sur mobile (vu que je ne connais que ça comme cas concret d’architecture ARM) n’a pas comme paradigme de remplir toute la RAM pour ne pas avoir de RAM inutilisée justement ?
Après je sais pas si c’est dû à l’architecture ARM ou aux OS mobile.
Sinon sans déconner, on va avoir dès cette année des smartphones android avec plus de RAM qu’un MacBook Pro pour des perfs Llaaaaargement en dessous…
C’est aussi ce qui m’interesse, j’attends de voir les plug-in à jour pour savoir comment tout celà va marcher. Mais dans tous les cas, le nombre de pistes gérables dans Logic est bien plus important qu’avec mon bon vieux macbook air de 2015 !
Là je comprends pas trop comment une archi différente ferait à elle seule une telle différence. Par curiosité t’as un papier qui explique ça un plus dans le détail ?
Après, si le M1 est taillé aux petits oignons pour MacOs BigSur, effectivement ils ont pu faire des optimisations, mais arriver à un ratio x6, je trouve ça dingue.
CF plus haut les histoires de garbage collection sur x86 et pas sur M1, c’est expliqué dedans.
Ok en googlant j’ai trouvé des explications et je suis retombé sur l’article de Daring Fireball que tu as linké le 18 novembre :ninja:
J’ai aussi trouvé cet article (en deuxième lien google, mais aussi référencé par mon nouveau pote Darring) sur:
J’en retiens que MacOs n’utilise pas le garbage collector pour gérer les objets mémoires, mais un référence count. Ce qui a 2 avantages principaux, c’est plus rapide et ça consomme moins de RAM.
Donc là on parle bien d’un avantage de l’OS, la puce n’y est pour rien. Qui s’applique aussi au X86 d’ailleurs.
Ce qui rend le M1 particulier c’est qui l’embarque en hard les opérations nécessaires pour gérer le RC à la même vitesse qu’un load/store.
(Cf l’échange sur twitter rapporté dans l’article de David Smith un ingé d’Apple).
Darring explique aussi pourquoi, quand ça swap parce qu’il n’y a plus de RAM dispo, c’est plus rapide, là le M1 aide avec son design.
1 « J'aime »
Alors là en fait c’est une mauvaise interprétation lié au fait qu’il est très succinct sur ce passage. L’utilisation d’un GC n’est pas faite dans les couches basses de l’OS mais au niveau du runtime des langages applicatifs. En plus concis c’est le fait d’utiliser à la base de l’Objective-C qui a entrainé l’usage du reference count. Si demain tu créés un nouvel OS codé en Rust ça sera pareil. Par contre sur Android ils étaient parti sur du Java qui utilise un GC, de même pour C#. Or sur Android la quasi totalité du user land (les applications, mêmes les applications systèmes) sont codés en Java ou une variante qui tourne sur la « VM » Java (Kotlin par exemple). De même depuis quelques années Microsoft pousse pas mal C# qui utilise aussi un GC. Et oui un GC ça a un effet de levier multiplicateur sur la consommation de mémoire.
Mais du coup cela ne permet pas d’expliquer la différence entre X86 et ARM sur un Mac, vu que là les principes sont les mêmes. Donc faudrait franchement pousser l’enquête bien plus loin car les facteurs peuvent être multiples.
Au final, je pense surtout que ce qu’on sous estime, et là l’article le souligne bien, c’est les efforts fait par l’équipe de développement de l’OS pour optimiser l’usage de la RAM par les applications. Et souvent l’optimisation des applications n’était que secondaire chez les autres avec certaines équipes connues pour bourriner comme des sacs au niveau de la RAM (oui les mecs de chez Chrome, on vous voit). Parce que la RAM était vu comme une commodité et que finalement l’utilisateur avait qu’à en rajouter. Mais nous arrivons dans des temps où la sobriété est de rigueur et certains l’ont compris plus que d’autres.
1 « J'aime »
Oui tu as tout à fait raison, je voulais éditer et j’ai oublié…
Par contre je connais pas du tout la programmation MacOS, les NSObject dont ils parlent, ça sert à quoi? A manipuler des ressources de l’OS ?
Et du coup ça n’explique pas trop pour Office qui selon les infos est principalement codé en C++…
1 « J'aime »
Je sais pas si c’est toujours le cas, mais à une époque Office Mac était développé par une équipe dédiée, séparée du reste.
Non en fait c’est la classe de base quand tu définies des objets en objective-C, mais vu que tout l’OS a été construit avec, toutes les ressources que tu manipules sont bien des NSObject. Même si maintenant Apple a tendance à plus pousser Swift vu qu’Objective C avait tendance à filer de l’eczéma à pas mal de gens (c’est un peu exotique on va dire comme langage, surtout au niveau du cycle de vie des objets)
Comme dit là faudrait pousser plus loin l’investigation, ça peut être simplement un truc con genre au portage ils en ont profité pour nettoyer le code et l’optimiser.
Depuis environ 2 ans le « code source » d’office est exactement le même pour Windows et macOS.