Keynote d’Apple : Apple Silicon fait son arrivée sur le MacBook Air, le Mac mini et le MacBook Pro 13", Réactions à la publication du 10/11/2020

[bob II]

Sur ce fil de discutions quels sont celles ou ceux qui ont commandé un Mac ARM alors ?
Se serait sympa de nous dire ce qu'il en est réellement quand vous l'aurez reçu.
Merci d'avance

[davdenice]

Un Mac avec 8Go de RAM ... à condition de passer son temps à fermer des logiciels avant d'en démarrer d'autres, sinon la mémoire est vite saturée.

[malloc]

Un Mac avec 8Go de RAM ... à condition de passer son temps à fermer des logiciels avant d'en démarrer d'autres, sinon la mémoire est vite saturée.

Faut pas pousser non plus.

Je travaille tous les jours sous 8Go de ram, j’ai pas l’impression de manquer!

[iAPX]

Un Mac avec 8Go de RAM ... à condition de passer son temps à fermer des logiciels avant d'en démarrer d'autres, sinon la mémoire est vite saturée.

Faut pas pousser non plus.

Je travaille tous les jours sous 8Go de ram, j’ai pas l’impression de manquer!

Je ne doute pas que ça soit possible, mais là je serais un peu curieux de savoir quels logiciels tu utilises, et quel version de macOS tu utilises sur quel Mac?
(oui suivant le modèle du mac et la version de macOS tu peux avoir jusqu'à 2.5Go de RAM en plus disponible, encore plus si tu utilises un vieil OS X!)

Par exemple un iMac 8Go avec dGPU offrira plus de 5Go de RAM pour les applications sous macOS 11 Big Sur, alors qu'un MacBook Air 8Go Intel avec iGPU (paf 1.5Go de RAM en envolé!) sous macOS 10.15.7 offrira approximativement 3Go pour les applications, un facteur qui si on y ajoute les 1Go+ nécessaire pour un bon cache disque (macOS s'en assure!) fait plus que doubler l'espace réellement disponible pour les applications.

Il est aussi à noter que le stockage Flash extrêmement rapide de nos Mac actuel arrive à sauver les meubles quand ça swappe mais au prix d'une usure incroyablement accélérée du stockage (et donc d'une mort prématurée de celui-ci ainsi que du Mac puisque soudé), ce qui peut tromper des utilisateurs ne s'apercevant pas que leur machine, comme les canards, sont calmes en surface mais pédalent à fond dessous.

Une anecdote à ce sujet, un développeur front-end qui avait donc à la fois besoin de se coltiner l'exécution du backend en local et ses outils front-end pour travailler (la pire situation) trouvait son Mac 16Go peu réactif. Il avait 8Go de swap avec des échanges incessants. 50% de sa RAM réelle en SWAP, j'avais jamais vu autant de pression sur le sous-système mémoire.
C'était incroyable pour moi que la machine tienne sans s'écrouler magie du stockage Flash et des excellents contrôleurs Apple.
Mais, in-fine, un quad-core avec 16Go bien plus lent que si ça avait été un dual-core avec 32Go de RAM!

Ce message a été modifié par iAPX - 13 Nov 2020, 23:01.

[jeandemi]

PS: pour les CISC vs. RISC, RISC a gagné et c'est flagrant avec nos smartphone mais aussi le M1, et -en fait- c'était déjà évident depuis le Core™ 2 pour Intel (voir le Pentium Pro!) et le K5 pour AMD qui héritent l'un et l'autre d'une unité d'exécution RISC. Il n'y a plus débat et ce depuis longtemps. L'article de AnandTech met en avant un autre avantage de la philosophie RISC (l'encodage des instructions donc l'unité de décodage et les limites associées).

Pourtant, le PowerPC était un processeur RISC, comme le DEC Alpha, l’Intel Itanium et d’autres qui ont disparu face aux CISC x86 et AMD64 qui n’arrêtent pas de se complexifier (instructions MMX puis SSE...)

Quand à la quantité de RAM nécessaire à Mac OS, j’ai une fois lancé Mojave avec juste 2GB, et ça a démarré (bon, on ne pouvait rien faire sans swap)
Avec 8GB sous Sierra, (mais avec une carte graphique PCI-E), Capture One 11 traitait très bien mes images RAW 24MPixels. Je n’ai pas senti de différence en passant à 16GB

Donc pour une utilisation basique, 8GB peuvent largement faire l’affaire
Quand à l’utilisation à long terme, il faut voir si ces machines seront fiables, Apple n’a pas montré que du bon ces dernières années. Tu peux très bien prendre 16GB en te disant « c’est pour le futur » et que dans 3, 4 ou 5 ans l’ordi est en panne à cause de la batterie, du clavier ou du SSD évidemment impossible à remplacer car collé ou soudé

[iAPX]

PS: pour les CISC vs. RISC, RISC a gagné et c'est flagrant avec nos smartphone mais aussi le M1, et -en fait- c'était déjà évident depuis le Core™ 2 pour Intel (voir le Pentium Pro!) et le K5 pour AMD qui héritent l'un et l'autre d'une unité d'exécution RISC. Il n'y a plus débat et ce depuis longtemps. L'article de AnandTech met en avant un autre avantage de la philosophie RISC (l'encodage des instructions donc l'unité de décodage et les limites associées).

Pourtant, le PowerPC était un processeur RISC, comme le DEC Alpha, l’Intel Itanium et d’autres qui ont disparu face aux CISC x86 et AMD64 qui n’arrêtent pas de se complexifier (instructions MMX puis SSE...)
...

C'est une sujet passionnant et sujet à polémiques, je ne détiens pas la vérité et je serais probablement contredit avec justesse, mais...

TL;DR RISC a gagné mais peut-être avec un jeu d'instruction CISC, ou RISC, ça se discute!

Le PowerPC était un processeur RISC, mais... mais personne n'a investi en lui, démarrage fulgurant puis ça a littéralement fait dur surplace, et pire IBM était plus intéressé par les performances multi-thread en serveur (on peut en voir les conséquences sur les Power9 et Power10) que la mobilité. Forcément un PowerPC G5 dans un Mac portable allait cramer plus rapidement qu'un Pentium-4 (pour faire référence à une pub Apple).
Apple a remplacé le PowerPC RISC au bout des ongles par du x86 avec un front-end CISC et un backend RISC (plus tout à l'heure).

Alpha a été fantastique, largement 2x plus rapide que les Pentium 2 ou 3 à fréquence identique, j'en ai utilisé un sous Windows NT4 64 bits avec Visual C pour Alpha, du code C portable exécuté sur la plateforme Alpha 21064A à 225Mhz en 64 bits et un Pentium 2 à 300mhz en 32 bits (pov'ti bout de Pentium 2).
Peut-être avez-vous utilisé ce service Minitel sans le savoir, on a écrasé nos concurrents Lyonnais avec leur mini-ordinateur à 1 millions de francs avec une machine à 25 000 FF, en allant largement dix fois plus vite. Leur boss a félicité le notre (bon joueur le gars!).
Il a été refourgué par HP à cause du hype autour de l'Itanium 64 bits Intel, Amd a utilisé des parties de ses technologies dans les excellents K6, Athlon et Athlon64 qui -justement- ont fait du mal à Intel. Mais essentiellement, les Alpha sont morts pour des raisons purement commerciales et stratégiques, après avoir taillé des croupières à Intel (en faisant les beaux jours d'Amd!)

L'Intel Itanium n'est ni CISC ni RISC mais VLIW, il était mort-né, paix à ses cendres et oublions cette merde qui a essentiellement servi à des couillons pour enterrer deux très belles architectures RISC, HP-PA très prometteuse et Dec Alpha qui faisait plus que promettre.

les CPU "CISC" actuelles ne le sont qu'en apparence, leur véritable jeu d'instruction interne s'appuie sur une micro-architecture load-store avec une foultitude de registres et des instructions simples, et la différence principale (et majeure) entre une Intel, une Amd et l'Apple M1 est le jeu d'instruction utilisé en externe et traduit par l'unité de décodage (le front-end) mais certainement pas par l'organisation des unités d'exécution.
Mieux que ça, elles sont plus performantes dans les boucles courtes où elles exécutent des instruction RISC cachées sans faire appel au décodeur du jeu d'instruction externe CISC; c'est quand elles sont totalement RISC qu'elles sont le plus performant!

Le RISC a gagné pour le back-end et le jeu d'instruction interne (celles vraiment exécutées), mais il restait le doute sur l'avantage d'un jeu d'instruction très complexe, à longueurs variables, dont des versions courtes de celles-ci permettant de gagner en densité d'information contrairement à un jeu d'instruction simplifié avec une longueur d'instruction fixe (ou peu variable).
Jusqu'à présent, Intel puis Amd ont amené la démonstration visible et vérifiable de la première hypothèse.
Apple aujourd'hui amène de façon tout aussi visible et vérifiable que la seconde hypothèse pourrait être la meilleure.

Alors que leurs unités d'exécution en back-end sont très similaire (et RISC dans tous les cas), la seule différence vraiment tangible est l'unité de décodage qui est totalement lié au jeu d'instruction externe (celui qu'on connait et qu'on manipule en assembleur ou au travers de compilateurs), mais je ne pense pas que la démonstration d'Apple avec le M1 soit la fin de l'histoire, il reste des possibilités intéressantes à Intel et Amd comme de définir un sous-ensemble d'instructions existantes à décodage simplifié leur permettant de revenir dans la course au parallélisme interne de leurs CPU.
Il y a aussi -évidemment- la possibilité de passer le SMT de 2 à 3 voir 4 voies comme le fait IBM ou d'autres, là aussi pour enlever la complexité exponentielle des unités de décodages d'instructions et littéralement abuser des caches d'instructions décodées de manière massive (les boucles quoi).

Donc je ne suis pas sûr qu'un jeu d'instruction soit intrinsèquement meilleur qu'un autre, au fil du temps ça a changé dans une direction puis l'autre, et l'histoire est loin d'être terminée.
En revanche, toutes les CPU modernes sont bâties sur des unités d'exécution RISC. Sans exception.

PS: vous seriez étonnés des milliers d'instructions dans les architectures "RISC" aujourd'hui, contre une centaine dans les anciennes CISC d'hier, ce qui caractérise le RISC est maintenant essentiellement un gros tas de registres généraux (et bien plus de registres réels pour le parallélisme) et une micro-architecture load-store (tout passe par les registres, les opérations ne modifient pas la mémoire directement) associé à un jeu d'instruction à longueur relativement fixe (oui relativement).
Et généralement un modèle mémoire "laxiste" ou rien n'est garanti sauf verrouillages explicites, écritures forcées, etc. Un casse-tête en assembleur pour du multi-thread!

Ça amène des complexités insoupçonnés, comme un simple incrément mémoire (une instruction externe) sur Amd64 (aka 86-64) se traduit par 3 instructions internes, les mêmes qui permettrait de le faire avec le jeu d'instruction Arm, mais en plus la nécessité de verrouiller la ligne de cache pendant l'opération, une différence fondamentale entre le modèle d'architecture x86 (verrouillages implicites et garantis) et Arm (verrouillages explicites), là aussi ça a un impact négatif sur les performances mais garantissant l'intégrité (sur Arm, modifier des données partagées entre thread est un cauchemar en revanche).

Ce message a été modifié par iAPX - 14 Nov 2020, 01:32.

[Pat94]

Bonjour à tous,

Avant de parler dans le vide, d'avancer des théories fumeuses et de philosopher sur les techniques utilisées, il serait bien d'attendre les vrais tests (effectués par des indépendants) de ces soi-disant merveilleuses machines.

[malloc]

Je ne doute pas que ça soit possible, mais là je serais un peu curieux de savoir quels logiciels tu utilises, et quel version de macOS tu utilises sur quel Mac?
(oui suivant le modèle du mac et la version de macOS tu peux avoir jusqu'à 2.5Go de RAM en plus disponible, encore plus si tu utilises un vieil OS X!)

Un MBPro en 10.13, un autre en 10.14. A priori les "pires" en terme d'optimisation de la RAM par macOS.

Workflow typique:
- Mail avec plein (15+) mailboxes
- Safari 20 onglets
- Firefox < 5 onglets
- LibreOffice entre 5-10 docs ouverts
- Numbers < 5 spreadsheets
- Une VM Windows la moitié du temps
- Un tas de petites app (BBEdit avec une tétrachiée de documents, liée à CyberDuck pour faire de l'édition sur serveur SFTP distant), Skype

Bref, la RAM est certainement bien sollicitée mais pourtant tout reste réactif. Est-ce que ça swappe à mort? Peut être, je surveille pas les page faults.
Est-ce que ça abîme la durée de vie de mes Mac?
Peut être, mais le plus vieux de mes MBPro est de 2014, même s'il meurt demain je n'irai pas pleurer à l'obsolescence programmée.

[RichardM]

Apple fait du Apple. Ile ne vendent pas du matériel informatique mais une expérience utilisateur.

C'est bien pour ça que je (me) posais la question. Parce qu'Apple elle-même n'en parle pas (je pratique la marque depuis quelques années - euh, attendez, Apple][, Lisa... - pour bien connaitre son champ de distorsion ).

Certains benchmarks ont l'air de parler de 3,5GHz plutôt pour le CPU.

Bien à vous

Richard

[tchek]

Je ne sais pas si c'est le bon fil pour ce sujet chaud que je viens de lire, et qui m'interroge plus que d'habitude ?

https://sneak.berlin/20201112/your-computer-isnt-yours/

Pardonnez moi si ça n'est pas la bonne place, et merci au modos de me rediriger s'il existe déja un fil !

Santé !

Ce message a été modifié par tchek - 14 Nov 2020, 12:58.

[Pat94]

Je ne sais pas si c'est le bon fil pour ce sujet chaud que je viens de lire, et qui m'interroge plus que d'habitude ?

https://sneak.berlin/20201112/your-computer-isnt-yours/

Pardonnez moi si ça n'est pas la bonne place, et merci au modos de me rediriger s'il existe déja un fil !

Santé !

Bonsoir,

Serions-nous flické par Apple et consorts avec l'impossibilité de filtrer ces incursions avec le nouveau Mac OS 11, comment cela est-il possible ?
Je croyais dans ma naïveté que ces sécurités, avec enfermement dans l'écosystème, c'était que pour notre bien, comment les preux chevaliers de la pomme peuvent-ils faire cela , je suis choqué

[Guest_Matyu_*]

Faut pas pousser non plus.

Je travaille tous les jours sous 8Go de ram, j’ai pas l’impression de manquer!

Oui, moi aussi, j'utilise tous les jours un Mac avec 8 Go de RAM. Usage basique. Il m'arrive de occasionnellement vérifier le moniteur d'activité, parfois une légère pression sur la mémoire mais rien de grave, la machine reste réactive et ne ralenti pas.

Ce message a été modifié par Matyu - 4 Dec 2020, 16:29.