Terminal : Homebrew prépare sa version optimisée Apple Silicon

Nicolas Furno | 28/12/2020 à 16:30

Le gestionnaire de paquets Homebrew fonctionne pour le moment grâce à Rosetta sur les Mac Apple Silicon. Cet outil qui permet d’installer des programmes en ligne de commande prépare toutefois sa version optimisée qui lui permettra de fonctionner sans la couche d’émulation intégrée à macOS Big Sur. L’un de ses développeurs fait le point sur GitHub et évoque une sortie de la version finale dans les prochains jours.

Homebrew lui-même est optimisé Apple Silicon depuis longtemps, mais c’est la version Intel qui est toujours installée par défaut pour le moment. Il y avait quelques bugs à régler, mais ses créateurs voulaient surtout s’assurer que les programmes installés par le gestionnaire de paquets soient, eux aussi, compatibles avec les Mac Apple Silicon. C’est le cas d’au moins 70 % d’entre eux désormais, ce qui justifie la bascule sur la nouvelle architecture par défaut.

Pour les 30 % restants, soit on manque encore d’informations sur leur compatibilité Apple Silicon, soit il y a encore des points qui bloquent. Les développeurs sont encouragés à participer au projet pour corriger les derniers bugs et augmenter le nombre de paquets optimisés ARM.

Si vous comptez sur Homebrew, le mieux est d’attendre que cette mise à jour sorte, cela devrait se faire dans les prochains jours si tout va bien. Si vous en avez besoin immédiatement, la méthode n’a pas changé depuis la sortie des Mac M1 :

Comment utiliser Homebrew sur un Mac Apple Silicon

Source

@FCharlet

Vente flash sur de gros MacBook Pro M3 Max et iMac M3

Qualcomm dévoile un peu plus ses Snapdragon X, avec plusieurs variantes Elite et Plus

L'Union européenne grave dans le marbre le droit à la réparation et étend les garanties

Refurb : le MacBook Air M2 à seulement 1 019 €

vomi | 28/12/2020 à 16:45

Excellente nouvelle !

titigrou | 28/12/2020 à 16:50

J’attends avec impatience cela avant de passer sur un mac m1.
D’ailleurs si des personnes avec un mac m1 ont installé le logiciel AMC ( création de qcm) via homebrew, je serai ravis d’avoir leur retour! Vu que je l’utilise tous les jours sur macintel, je ne peux m’en passer comme ca du jour au lendemain!

Nicolas Furno | 28/12/2020 à 16:56

@titigrou

Je veux bien tester, mais « brew Install amc » ne donne rien, donc il me faut un coup de pouce. 🙂

robindumontchaponet | 28/12/2020 à 17:09

"brew install maelvls/amc/auto-multiple-choice" ?

Nicolas Furno | 28/12/2020 à 17:14

@robindumontchaponet

Merci, je vais tester. Longue liste de dépendances, je vois ! 😳

EDIT : désolé, ça plante sur gcc…

robindumontchaponet | 28/12/2020 à 18:15

Bon… C'est le cas aussi avec archi Intel de mon côté.
Headers qui manquent… ou un prérequis pas précisé…
Si je trouve, le temps je zieuterai (ça fera des choses à faire pour éviter de faire les choses que je suis censé faire normalement ^^), m'enfin vaudrait plutôt ouvrir une issue.

titigrou | 28/12/2020 à 20:14

@nicolasf

J’ai fais une documentation pour l’installation, je la cherche dans la soirée !

titigrou | 29/12/2020 à 00:01

Tutoriel fait à l'arrache il y a quelques mois pour AMC.
https://www.dropbox.com/s/t840wc0ey8eh5s9/Tutoriel%20V2.pdf?dl=0
je suis très intéressé par le retour!

Nicolas Furno | 29/12/2020 à 14:30

@titigrou

Merci, mais le souci sur les Mac Apple Silicon, c'est à l'étape d'installation avec Homebrew. Au moins l'une des dépendances n'est pas encore compatible pour le moment.

denPetrus | 28/12/2020 à 21:45

Je me suis acheté un Mac mini M1 sans tarder (pour remplacer mon vieillissant Mac Pro 2008). J'attends avec impatience que Homebrew soit opérationnel pour AMC et OCaml. Je testerai dès que ce sera possible

YetOneOtherGit | 28/12/2020 à 21:55

@denPetrus

"OCaml"

Un homme de goûts 👍❤️

titigrou | 30/12/2020 à 13:41

de mémoire, on peut installer AMC avec Macports aussi. J'y suis jamais arrivé sur intel. Sur M1 peut-être que ça fonctionne!

marc_os | 30/12/2020 à 18:42

@ denPetrus

A quoi ça sert OCaml ?
Dans quel contexte l'utiliser et quel intérêt par rapport aux langages classiques ?
Script ou langage à compiler ?
La page d'accueil de leur site https://ocaml.org/index.fr.html ne le dit pas.
C'est dommage.

YetOneOtherGit | 30/12/2020 à 20:14

@marc_os

"A quoi ça sert OCaml ?"

Un remarquable langage fonctionnel porté par le brillantisime Xavier Leroy et l’INRIA.

Un de les langage fonctionnel favori avec des niveaux de performance impressionnant.

Le fonctionnel revient en force depuis que ses pb de performance ont été réglés et OCaml voit ses usages s’étendre dans cette niche.

Dans les belles réussîtes basées sur ce langage il y a Coq un assistant de preuve qui a permis de certifié formellement CompCert, un compilateur C dont le fonctionnement est formellement prouvé (Absence de bug ce qui est paradoxalement rare pour un outil aussi essentiel qu’un compilateur)

Ou le Static Driver Verifier (SDV) de Microsoft pour certifier statiquement les drivers.

Ou les usages sur des applications en avionique.

Un des avantages des approches fonctionnel et de détecter beaucoup de problèmes dès la compilation avant le run-time.

YetOneOtherGit | 30/12/2020 à 20:15

@marc_os

"Script ou langage à compiler ?
La page d'accueil de leur site https://ocaml.org/index.fr.html ne le dit pas.
C'est dommage."

Langage compilé 😎

Les outils sont de grande qualité 👍

Tu n’as pas été trop loin sur le site:

https://ocaml.org/learn/description.html

Tu as pas mal d’informations de base là.

YetOneOtherGit | 30/12/2020 à 20:32

@marc_os

"quel intérêt par rapport aux langages classiques ?"

C’est amusant que le paradigme impératif soit devenu classique.

Le paradigme fonctionnel issu du Lambda calcul est très ancien, il est apparut avec Lisp juste un an après le premier langage de haut niveau qu’est Fortran.

L’approche fonctionnelle est déroutante quand on ne commence pas par elle mais très intéressante, elle a souffert pendant longtemps de soucis de performance mais revient en force depuis quelques années.

Dans les languages les plus porteurs de ce paradigme tu as Haskell, Erlang, Scala, F# et évidemment Lisp et Scheme.

Imagines programmer sans affectation 🤓

Bienvenue dans le monde du fonctionnel 😉

bunam | 28/12/2020 à 17:38

Ils ont fait un choix pour installer les binaires compatible M1 : /opt/homebrew
C'était mon choix sur de l'Intel grrr, j'ai du tout re-installer dans : /usr/local (burk)

J'aime bien aussi macports

YetOneOtherGit | 28/12/2020 à 19:40

Je suis le seul vieux con choqué par cette habitude abusive de parler de version “optimisée” ARM pour un portage ARM ?

lepoulpebaleine | 28/12/2020 à 21:24

@YetOneOtherGit

On est bien d’accord !

hillel | 28/12/2020 à 23:11

Pourtant ce n'est pas complétement faux. Les binaires x86 sont traduits par Rosetta sur les Macs ARM (et non emulées comme j'ai pu le lire un peu partout y compris ici)

La traduction reste automatique et des optimisations plus poussées ne peuvent être apportées que par un portage manuel

C'est un peu tiré par les cheveux mais on ne peut pas dire que l'expression optimisé pour ARM soit complètement fausse

YetOneOtherGit | 29/12/2020 à 00:06

@hillel

"Les binaires x86 sont traduits par Rosetta sur les Macs ARM"

Ce n’est pas du tout pour ce type de transpilation que le terme “optimisation” est généralement abusivement utilisé mais pour des portages en ARM natif.

Pour le reste l’emploi est tout aussi abusif dans le cas de Rosetta 2.

BeePotato | 29/12/2020 à 11:41

@ YetOneOtherGit : « Ce n’est pas du tout pour ce type de transpilation que le terme “optimisation” est généralement abusivement utilisé mais pour des portages en ARM natif. »

Ce que hillel faisait remarquer, c’est que c’est par contraste avec cette émulation que le terme « optimisé » est utilisé pour qualifier une version portée sur ARM.
Par rapport à cette version générée automatiquement, une recompilation pour ARM représente effectivement une nette amélioration.

Après, qualifier cette amélioration d’optimisation est bien un abus, mais un tel abus est quasi systématique pour ce mot : à chaque fois qu’on parle d’optimisation, on est en fait dans une situation où on a cherché à tendre vers un optimum mais sans aucune garantie de l’avoir atteint.

YetOneOtherGit | 29/12/2020 à 15:19

@BeePotato

"Ce que hillel faisait remarquer, c’est que c’est par contraste avec cette émulation que le terme « optimisé » est utilisé pour qualifier une version portée sur ARM."

Ce n’en est pas pour autant autre chose qu’un portage à force d’utiliser les termes en dehors de leur sens, ils se vident de sens. 😉

BeePotato | 30/12/2020 à 01:07

@ YetOneOtherGit : « Ce n’en est pas pour autant autre chose qu’un portage à force d’utiliser les termes en dehors de leur sens, ils se vident de sens. 😉 »

Le fait que ce soit un portage n’interdit pas que ce soit une version optimisée. ;-)
On ose même espérer que ce le soit, en fait. :-)

YetOneOtherGit | 30/12/2020 à 13:39

@BeePotato

"Le fait que ce soit un portage n’interdit pas que ce soit une version optimisée. ;-)"

Les optimisation liées au matériel sont aujourd’hui rarissime au niveau du code source et peu recommandé.

Désolé c’est clairement un abus de langage que d’employer optimiser en lieu et place de porté 🧐😉

IceWizard | 29/12/2020 à 13:52

@hillel
"C'est un peu tiré par les cheveux mais on ne peut pas dire que l'expression optimisé pour ARM soit complètement fausse"

Ouais, ouais et ça fait tellement plus branché dans les soirées mondaines, que "application native ARM" !

IceWizard | 29/12/2020 à 14:54

@hillel
"La traduction reste automatique et des optimisations plus poussées ne peuvent être apportées que par un portage manuel"

Pas vraiment. Il n'y a pas de "portage manuel".

Le principe de la programmation c'est de décrire le comportement d'une application dans un langage (relativement) proche de la compréhension de l'être humain (C, C++, Swift, Objective-C, etc ..). On stocke ça dans une série de fichiers textes qu'on appelle le code source.

Pour créer une application on utilise un outil appelé un compilateur qui prend un code source, pour le convertir en langage machine compréhensible par un processeur. C'est une opération complexe utilisant de nombreuses techniques d'optimisation propre au processeur.

La création d'une application en langage machine à partir d'un langage de haut niveau est connu depuis longtemps. Depuis 1954, avec le langage scientifique Fortran.

La conversion d'un langage machine vers un autre langage machine est beaucoup plus difficile, pour des tas de raisons comme l'horrible complexité techniques de ces langages, mais aussi toutes les optimisations réalisées lors de la compilation du code source.

Rosetta 2 ne convertit pas directement le code processeur Intel en code ARM. Il commence par analyser le code Intel pour essayer de comprendre ce qu'il fait et génère une sorte de programme source, dans un langage de haut niveau qui lui est propre. Il compile alors ce nouveau code source en code processeur ARM.

Le problème c'est que ce "code source analytique" n'est qu'une mauvaise copie du code source originel. De nombreuses informations manquent, et il y a beaucoup d'hypothèses plus ou moins exactes sur ce que le développeur voulait vraiment faire. D'où un résultat final moins efficace.

Pour créer un code processeur vraiment efficace, il faut avoir accès à toutes les informations définis dans le code source originel, rédigé par les développeurs.

Ce que tu appelles "portage manuel", c'est charger le code source originel dans Xcode, cocher la case "cible processeur Silicon Apple" et relancer une compilation.