[Apple M1] : Suite du bug des SSDs.

[Sethenès]

Je fais référence ici à l'article publié par Consomac le 24 février 2021 : Lien 

Je viens de tomber sur une vidéo intéressante qui nous en apprend un peu plus.

Que retenir ? Que comme ici et ailleurs, la toute grande majorité des utilisateurs n'a pas rencontré le problème. Ensuite, il semble que le problème soit lié à Rosetta 2 en conjonction avec l'usage de certains softs. Je ne les cite volontairement pas, car rien ne dit qu'ils ont quelque chose de particulier. Sur les Macs Intel, ces softs ne posent aucun problème.

Que tirer comme conclusion ?

1. Que le problème est probablement d'origine software, ce qui est plutôt une bonne nouvelle
2. Qu'il est potentiellement lié à Rosetta 2. Autrement dit que si les éditeurs souhaitent fournir une version pour ARM le problème devrait disparaitre
3. Enfin, qu'il n'est pas impossible que le problème se situe au sein de Rosetta 2 et qu'il puisse être corrigé par Apple (ou en tout cas, qu'il puisse être neutralisé par Apple, quitte à perdre en performance).

Vidéo : https://www.youtube.com/watch?v=nuOBsXOaP38 

Et voilà,

Sethenès

[LolYangccool]

@pehache « Apple n'a pas réussis à faire tenir 2 octets dans un ».
Référence à te petite moquerie. Eh bien il semblerait que ta moquerie ne soit pas tout à fait vrai. :P

[Sethenès]

Bon ... voici le suivi de cette vidéo. Je suis bien embêté car dès le départ, je sentais que ce ne pouvait pas être un problème critique et dès lors, l'idée d'un problème "soft" me paraissait très crédible.

Par contre, vous allez vous rendre compte à la lecture de ce qui suit que la résolution de ces problème est moins simple qu'il n'y parait.

Jusqu'ici, je n'avais pas poursuivi la discussion sur le problème des SSDs mais voici les réponses de deux intervenants actifs sur un autre forum où j'avais posté en même temps exactement le même message que sur le forum de Consomac :

Source : Lien (A noter que les deux intervenants sont pour l'un modérateur du forum et pour l'autre rédacteur du même forum. Cela donne quand même un gage de sérieux. De plus, l'apparente qualité des interventions m'incite à leur donner du crédit)

Intervenant 1 : 

Citation

Concernant les applications développées à partir de Chromium (qui pourraient être parmi les suspects principaux), il est quand même de notoriété publique que même sous Intel, ce sont des gouffres à mémoire. De plus, elles sont programmées pour maximiser l'usage du swap."

Intervenant 2 :

Citation

 

Et surtout, il y a plein d'applications qui ne sont pas des navigateurs mais qui sont quand même basées sur Chromium, sans que tu les saches forcément. De plus en plus souvent, quand un service en ligne sort une application "native" pour l'utiliser sans passer par le navigateur, c'est en fait une web app + chromimum packagés ensemble dans une pseudo application native... Ça simplifie énormément le développement, vu que ça permet de réutiliser le code de l'UI de la version web, mais par contre c'est un gouffre en ressources... C'est comme ça que tu te retrouves avec un bête client de messagerie instantanée qui te prends 350 Mo de stockage et 100 Mo de RAM...

Quelques exemples connus : Skype, Teams, Slack, Discord, Signal, WhatsApp, Visual Studio Code, Atom, Steam, Postman, Draw.io... 

 

Or, dans la vidéo que j'avais mentionné, il était question entre autre de Discord justement.

Voilà exactement le type de problème contre lequel je mets en garde depuis pas mal de temps ! C'est le résultat d'une version d'un soft non optimisé pour OSX (x86) qui fait "combo" avec une application pour ARM, Rosetta 2. 

Ce que j'affirme (sans preuves bien sûr), c'est que si les parts de marché d'OSX étaient de l'ordre de 25% ou plus, ce problème de gestion mémoire avec Chromium serait depuis longtemps résolus. Car ce n'est évidemment pas un problème de Hardware du Mac, ni d'OSX, l'OS du Mac. Le problème est bel et bien dans Chromium puisque ce problème n'existe pas sous PC.

A ce stade-ci, je voudrais préciser que ce problème apparait probablement avec Chromium mais que rien n'indique qu'il n'y ait pas d'autres logiciels ou couches logicielles qui n'occasionnent le même problème. 

La responsabilité est claire mais ... qui va résoudre le problème ? Chromium est un logiciel libre, donc question responsabilité ... C'est important car il faut quand même rester raisonnable si on incrimine de tous les maux des gars qui codent sur leur temps libre et accepter qu'ils choisissent où investir ce temps libre.

 Alors quelles sont les solutions ?

1. Envisager que Chromium ponde une version pour Mac ARM. C'est possible, voir probable mais pas certain. D'autre part, si la version Mac connait des problèmes connus de longue date, cela donne une idée de l'empressement qu'il va y avoir à développer une seconde version pour Mac. Signalons que sur la page wiki consacrée à Chromium, le premier langage de programmation référencé est ... l'assembleur ! Et l'assembleur ARM c'est assez différent de l'assembleur x86 ... Même la version Linux doit être codée sous x86 ! D'ailleurs si vous voulez avoir une idée de la situation de Chromium sous ARM ... on vous explique comment la compiler pour ARM ... Bref ... 
2. Envisager que Chromium corrige le problème de base, sous x86. S'ils ne l'ont pas fait jusqu'ici sans compter qu'en plus ... il faudra prier pour qu'Apple supporte Rosetta 2 trrrrès longtemps.
3. Apple pourrait modifier Rosetta 2 pour contenir l'usage du swap. Techniquement, c'est certainement possible. Par contre côté perf ... Rosetta 2 risque d'en prendre un coup.
4. Envisager que chaque développeur de chaque application ponde une version ARM ne me semble pas une option puisque l'intervenant 2 nous explique que le but de Chromium est de transformer une Web-App en exécutable. Le cœur de métier de tout ces dev est donc bien de développer des Web-App et pas du code bas-niveau.
5. ?

Alors évidemment, c'est clair, ce problème est sporadique et ne concerne qu'une poignée d'utilisateurs ... jusqu'ici en tout cas. Il faudra voir si avec l'arrivée d'utilisateurs plus exigeants, ce problème ne va pas croître. 

Je vais peut-être trop loin, mais cela m'incite à réinterpréter la communication à propos de la fin de Rosetta 2 dans certaines régions. Le message était peut être adressé aux développeurs pour qu'ils ne trainent pas trop à proposer une version native pour ARM.

Par contre là où je persiste, c'est qu'Apple peut circonscrire le problème et adopter un point de vue défensif afin de protéger le SSD de ses clients. Même si ce n'est pas sa responsabilité directe, n'attendrait-on pas cela d'un professionnel diligent ?

[Fred4]

S'agissant des applications basées sur Chromium, si une version optimisée pour iOS sans Chromium existe (fort probable) et qu'elle soit exécutable sur Mac ARM sans souci (probable à moyen terme), dans ce cas ce serait une alternative moins préjudiciable au SSD.

Resterait toutefois l'ergonomie qui est développée pour iOS et qui sera souvent moins confortable sur macOS qu'une application native pour ARM.

Modifié 21 mars 2021 par Fred4

[pehache]

Je n'ai pas envie de me cogner une video de 12mn qui va expliquer un truc qui pourrait être expliqué en 1mn si c'était écrit... Néanmoins :

1) les web app packagées dans une appli classique sont effectivement des gouffres en ressources, car elles embarquent une instance complète d'un moteur de rendu HTML. C'est celui de Chromium (Blink) est qui est choisi la plupart du temps car c'est le plus populaire, mais le problème serait exactement le même avec n'importe quel autre (Webkit, Gecko...) car ils sont tous des gouffres à ressources.

2) Contrairement à ce qui est dit dans les commentaires, ces apps posent tout autant problème sur x86 que sur ARM : Whatsapp web occupe en tout 800Mo de RAM sur mon iMac, et avec Skype en plus (400Mo de RAM) j'arrive à 1,2Go de RAM occupée et ça augmente significativement mon usage du swap (alors que j'ai 12Go de RAM). Il est possible que Rosetta 2 ajoute une occupation RAM supplémentaire qui va aggraver le problème (du simple fait que le code binaire ARM est plus gros que le code binaire x86, déjà), mais ça ne va pas être un facteur 10 non plus.

3) Ca ne peut pas expliquer l'usure si rapide de SSD tels que rapportée dans certains cas. Pour moi ces cas proviennent d'usages intensifs et très exigeants en RAM (type montage video) : habituellement ceux qui ont ce type d'usage avaient des Mac bien burnés en RAM, 16Go voire 32Go. Là une poignée de blogueurs pignoufs à la solde d'Apple leur a seriné qu'avec 8Go désormais on en faisait autant qu'avec 32Go avant : oui, mais en sollicitant à mort le SSD rapide pour faire du swap, avec les conséquences que l'on voit.

Modifié 21 mars 2021 par pehache

[Sethenès]

Pour le point 2), OK. La manière dont l'info est présentée m'a peut-être fait interpréter les choses de travers avec un différentiel entre l'usage de la mémoire sous Mac et sous PC. J'ai essayé de trouver un article qui comparait les deux mais les seuls que je trouve concerne Chrome vs Safari ...

Pour le point 3), je comprends ta logique @pehache et je serais enclin à la partager mais en fait ce qui découle des nombreuses captures d'écrans présentées ailleurs ou des chiffres qu'on a pu voir dans les commentaires du post original de Sylvain, ce qu'on observe n'est pas un usage intense "habituel".

Au contraire, il s'agit de problèmes chez quelques utilisateurs, avec dans un cas un usage de 10% du SSD après moins de 3 mois. Ce qui n'est (selon moi) pas possible c'est d'avoir 99,9% d'utilisateurs sans problèmes et 0,00..1 % à "gros problèmes". Il faudrait une distribution, en forme d'exponentielle décroissante entre ceux qui montent des vidéos un peu, beaucoup, à la folie, ... . Ici ce n'est pas le cas. En gros, c'est "tout ou rien".

D'autre part, dans la vidéo, il est clairement question de Discord (et de quelques autres) qui n'est quand même pas l'équivalent d'un logiciel de montage avec un usage intensif de la RAM.

Car au fond, si on suit ta logique d'un "simple" usage trop intensif dans un environnement où la mémoire est sous stress (et donc le swap), Apple devait savoir que son Rosetta 2 allait provoquer ces soucis. Et cela je ne le crois pas car toujours dans une logique d'usage légitime, dans 2 ans, la frange d'utilisateurs à problèmes devrait exploser. Depuis cette news, un paquet d'acquéreur monitorent certainement cet usage. Or à ma connaissance, il n'y a pas de multiplication des cas. 

Selon moi, soit il y a un énorme bug quelque part, soit c'est la conjonction de plusieurs facteurs mais avec malgré tout un élément "spécifique" qui fait que soit Apple ne l'a pas décelé dans ses tests, soit qu'elle est passée outre (en ayant identifié ou pas la raison d'ailleurs).

Rappelons que les "grosses" configs ARM ne sont pas encore sorties et que si ce problème de mémoire était "bien connu", cela pourrait quand même sérieusement entaché la réputation des Macs ARM, surtout a fortiori avec des SSDs soudés !

@Fred4 : oui, j'avais aussi pensé à la solution iOS (et à quelques autres en plus) mais ce n'est quand même pas une solution très élégante comme tu le signales toi-même.

[Sethenès]

Entretemps, j'ai posé la question sur Mac Bidouille à Baron (l'intervenant 1).

Voici ma question :

Citation

Baron, je reviens sur ce que tu écris ici. Présenté de la sorte, il y a une (petite) ambiguïté et j'aimerais la lever.

Est-ce que c'est la gestion de la mémoire de Chromium qui est problématique et alors la situation est la même sur PC x86 et Mac x86 ou y a-t-il dans le cas d'OSX un problème particulier qui fait que la gestion de la mémoire sous Chromium est "encore" plus mauvaise sur Mac que sur PC ?

Et un extrait de sa réponse :

Citation

Réponse brève : les deux, mon général.

(...) Ensuite, il se peut que l'implémentation pour macOS en général ou plus spécifiquement pour les Mac Silicon (M1) soit plus pénalisante encore. Je n'en sais trop rien, je ne suis aucunement spécialiste, mais 1º il ressort de la lecture de leur documentation que le développement de Chromium est d'abord axé sur les systèmes Windows et Androïd, 2º une recherche Google faite aujourd'hui avec les mêmes critères que dans mon message ci-dessus semble montrer que ça a en tout cas été le cas depuis très longtemps et jusque très récemment.
Voir p.ex. cet article qui vient en tête, avec un renvoi vers le blog Chromium : « Chrome is also shrinking its memory footprint in background tabs on macOS, something we’ve been doing on other platforms for a while. We’re seeing up to 8% memory savings, which is more than 1GiB in some cases! »
 

Ma "conclusion" :

Tout d'abord, cela explique pourquoi Chrome est plus gourmand que Safari par exemple (voir entre autre le graphique dans la discussion, le lien est en bas de page). Et oui, les problèmes de mémoire sont également présent sur PC.

Par contre, ceci me conforte (et je l'analyse en tout cas comme tel), que la faible part de marché d'OSX a comme conséquence qu'il est traité comme un OS de seconde zone, profitant des avancées avec retard ("for a while" est quand même assez clair. Ce n'est pas "recently").

Si les devs eux-mêmes signalent qu'il est possible, grâce à ces améliorations de gagner jusqu'à 1 GB (pour peu que GiB soit bien l'équivalent de GB), c'est quand même que les améliorations en questions étaient reconnues comme très utile.

Discussion originale : Lien

[pehache]

Il y a 2 heures, Sethenès a dit :

Au contraire, il s'agit de problèmes chez quelques utilisateurs, avec dans un cas un usage de 10% du SSD après moins de 3 mois. Ce qui n'est (selon moi) pas possible c'est d'avoir 99,9% d'utilisateurs sans problèmes et 0,00..1 % à "gros problèmes". Il faudrait une distribution, en forme d'exponentielle décroissante entre ceux qui montent des vidéos un peu, beaucoup, à la folie, ... . Ici ce n'est pas le cas. En gros, c'est "tout ou rien".

C'est au contraire très cohérent avec une distribution gausienne des usages, avec une ultra-minorité qui a un usage ultra-intensif.

 

Il y a 2 heures, Sethenès a dit :

Car au fond, si on suit ta logique d'un "simple" usage trop intensif dans un environnement où la mémoire est sous stress (et donc le swap), Apple devait savoir que son Rosetta 2 allait provoquer ces soucis.

Mais pour moi ça n'a rien à voir avec Rosetta. Oui les apps avec un moteur de rendu HTML embarqué consomment beaucoup de RAM, oui peut-être d'autant plus avec Rosetta, mais jamais ça ne va user un SSD aussi vite que rapporté.

 

[Sethenès]

il y a 1 minute, pehache a dit :

C'est au contraire très cohérent avec une distribution gausienne des usages, avec une ultra-minorité qui a un usage ultra-intensif.

 

Mais pour moi ça n'a rien à voir avec Rosetta. Oui les apps avec un moteur de rendu HTML embarqué consomment beaucoup de RAM, oui peut-être d'autant plus avec Rosetta, mais jamais ça ne va user un SSD aussi vite que rapporté.

 

Avec une gaussienne tu as forcément des entre-deux. Ici, soit la situation est normale, soit totalement anormale. Il n'y a pas d'entre-deux.

Prenons un cas concret. Une situation à 10% du SSD déjà utilisé (qui est un cas reporté). Imaginons un écart-type à 1%, ce qui est énorme vu que cela veut dire que 2/3 des utilisateurs ont < 1% et 1/3 > 1% (exactement 1 / 3,1514872).

10% représente 10 écarts-types. Déjà avec 7 écarts-types, il n'y a plus, statistiquement que 1 cas sur 390 682 215 445 possesseur de MAC ARM (c'est quand même 48x la population terrestre).

Source pour les deux valeurs : https://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distributed_data

Dès lors, tout le reste du raisonnement suit évidemment. Rosetta 2 fonctionne correctement dans la toute grand majorité des cas mais dans une situation particulière, il y a "combo" et emballement.

Une autre manière d'analyser le problème est que justement, avec tous les Macs Intel qui sont équipés de SSD, ce problème n'a jamais été signalé. Evidemment, depuis, tous les possesseurs de SSDs (moi le premier), avons fait ces tests en ce compris sur des machines anciennes. Or s'il s'agissait uniquement de problème sporadique lié au manque de mémoire et à l'usage de soft de montage, il y en a quand même un paquet d'utilisateurs qui "montent" sur des vieux macs équipés seulement de 8GB d'un petit SSD (et je ne parle même pas du fusion drive).

[Fred4]

La pagination me semble quand même utilisée de manière très agressive sur les Mac M1, nettement plus que sur les Mac intel à première vue. Je pense notamment aux données que @pim nous avait communiquées à ce sujet.

Y compris dans des situations où la pagination serait superflue, la gestion de mémoire semble privilégier une sous utilisation de la mémoire vive, peut-être pour la réserver aux potentielles nouvelles tâches et maximiser la réactivité.

À force de trop miser sur la performance du SSD pour compenser la quantité fixe de mémoire vive, dans certains cas particuliers d’utilisation, l’effet d’emballement pourrait se produire.

Sur les Mac intel, macOS adopte peut-être une stratégie moins agressive, ne présupposant pas la présence exclusive d’un SSD ultra rapide?

Modifié 22 mars 2021 par Fred4

[pehache]

Le 21/03/2021 à 16:37, Sethenès a dit :

il y en a quand même un paquet d'utilisateurs qui "montent" sur des vieux macs équipés seulement de 8GB d'un petit SSD

Personne ne faisait ça de façon intensive sur un Mac Intel aussi peu doté en RAM, car on se rendait vite compte que ça coinçait.

[Sethenès]

De mes différentes lectures, il y a un élément qui ressort : Les Macs avec puces M1 utilisent massivement le swap, tout comme Rosetta 2 en prime.

Ce qui n'est pas clair pour moi, c'est la raison. Est-ce un choix d'Apple ? Si oui, pourquoi ? Pour démontrer à quel point les puces Apple Silicon sont puissantes ? Si ce n'est pas un choix d'Apple mais une nécessité, pourquoi ?

Mais intéressons-nous un moment aux conséquences de cette situation. Je commence à voir de plus en plus le conseil de ne pas prendre d'Apple M1 à 8 GB parce que c'est une erreur, tout comme de ne pas prendre l'option à 256 GB (disons-le clairement, c'est l'option à 1TB qui est privilégiée). La raison invoquée n'est pas la performance, ni la valeur de revente, ni le confort d'utilisation, non. La raison invoquée est de protéger la durée de vie du SSD.

Et là, ça pose quand même question. La logique sous-jacente est claire : si on a besoin de 12 GB de RAM et qu'on en a 16, il n'y aura pratiquement pas de swap (il y en a toujours un peu) alors que si on a que 8GB de RAM ... De même, prendre un SSD plus grand, c'est avoir plus de cellules surnuméraires ... autrement dit, on est bien confronté au problème mais on ne le voit pas pendant plus longtemps !

Il y a évidemment une option simple qui serait de ne pas avoir le SSD soudé. Mais bon ... A côté de cette solution trop simple pour être retenue, les questions posées sont multiples.

Le prix pour une config (MBA) avec 1TB de SSD et 16GB de RAM est de 1860 euros. Si on le compare au MBA d'entrée de gamme à 1130 euros, cela représente un facteur de 1,64. La question peut donc se poser en ces termes, est-ce que le MBA de base à 1130 vivra moins des 2/3 de la machine à 1860 euros ? A titre personnel, je précise que je conseillerais toujours le MBA à 8GB / 256GB., sauf s'il y a un usage intensif de Rosetta 2 (par exemple avec Chromium).

Mais est-ce à l'acheteur de prendre ce risque ? Je veux dire, est-ce à l'acheteur de composer avec une usure anormale ? Bien sûr que si on achète une perceuse à 500 euros, elle aura une autre durée de vie et un autre usage qu'un perceuse à 100 euros. Mais la machine en elle-même est différente. Ici, c'est la même machine, ce sont juste les options qui changent.

Une autre manière de présenter les choses n'est-elle pas de considérer que le prix de l'entrée de gamme est de 1630 euros (16GB, 512 GB de SSD) ? D'une certaine manière, c'est un désavantage du Mac M1 à prendre en considération à l'achat (et aussi, et surtout, dans les analyses qui sont faites de cette solution).

Alors revenons-en aux motivations. Une chose est claire pour moi, c'est qu'Apple a la possibilité, dès aujourd'hui de remédier à la situation. Il suffit de modifier les réglages d'OSX et de Rosetta 2. Le fait-elle ? En tout cas, c'est possible. Il serait intéressant de refaire les premiers benchs d'OSX/M1 et de Rosetta 2/M1 pour voir si les performances ont chuté depuis les mises à jour de Big Sur. J'imagine qu'a minima les benchs des nouvelles puces M1+/M2 à venir seront réalisés, tant avec OSX qu'avec Rosetta 2. Il sera intéressant de vérifier les différences (pour peu, évidemment, qu'il y ait des modèles à 8GB).

Cette décision ne me choquerait pas, je préfèrerais qu'ils communiquent plutôt que de le faire en douce ..., mais la plus mauvaise option est de ne rien faire. Evidemment si les message est n'acheter que les configs à 1630-1860 euros plutôt que celle à 1130 ... pourquoi s'en priver ... (voir la news d'hier avec iMessage).

Je n'irais pas jusqu'à dire que cela a été fait en "exprès" pour vendre des configs plus chères, mais mon avis est clair. Ils savaient que c'était très limite et ils se sont assis dessus, juste pour marquer les esprits. 

De ce côté là, c'est très réussi d'ailleurs. Il suffit de voir les réactions. La puce M1 est meilleure en tout. Point. Critiquer la puce M1 aujourd'hui, c'est comme critiquer le Professeur Raoult il y a un an !

Evidemment, ils ne pensaient peut-être pas être découvert (ou pas aussi vite en tout cas) à cause des quelques cas vraiment problématiques.

[Apple4ever2021]

D'accord avec toi ! Un peu déçu que la pomme ne communique pas sur ce point qui semble délicat s'il s'avère être vérifié et exact ...

[Theozz]

Sur les forums de Macrumors, certains utilisateurs indiquent qu'en changeant de navigateur (Brave ou Firefox au lieu de Safari) le swap a drastiquement chuté. Il s'agit d'utilisateurs qui ne fermaient jamais les onglets, et qui expliquent que contrairement à Safari sur iOS, la version macOS ne met pas en veille les onglets non-utilisés.

Je ne sais pas si ça apporte au sujet de Rosetta 2 mal optimisé, mais je trouvais intéressant de l'indiquer.

Modifié 20 avril 2021 par Theozz