Rendering VT-100 émulant l'affichage DOS

J'écris des moteurs d'échecs, ou d'autres comme pour le Reversi/Othello, depuis plusieurs décennies.
Je suis en train de travailler sur un moteur sorti fin 1994 pour le Minitel, écrit en C-Ansi, Borland C 3.1 pour DOS à l'époque et gcc maintenant pour Posix dans un terminal VT-100, 32 bits pour Pentium [1] à l'époque et 64 bits pour x86 et ARM aujourd'hui.
Du vieux code monothread, c'est à noter.

Et pour m'amuser, sur mon Mac mini M4, je ne fais non pas tourner une version compilée pour ARM mais celle compilée pour x86 64 bits. Le même exact code, grâce à Rosetta 2.
Ce code x86 sort de gcc, avec l'option -O3 : optimisé mais en limitant les risques.

Je viens de m'apercevoir que si en moyenne un cœur Performance du M4 est 3,3 fois plus rapide que chaque cœur de mon MBP 15" 2017, ce qui devrait amener ce code x86 monothread à tourner moins de 3 fois plus vite sous ARM via Rosetta 2 (85% d'efficacité mesurée en 2020), il tourne en fait 4 fois plus vite maintenant en 2025!

Je soupçonne que Rosetta 2 s'est vu amélioré et pourrait utiliser les 16 registres généraux en plus de l'architecture ARM 64 bits pour optimiser le code x86 quand il le transcrit pour nos Mac Apple Silicon.
Ce code simple (non-vectoriel, non fpu) tourne 30% plus vite qu'il le devrait !

Une limitation du Amd64 (ou x86 64 bit, ou x86-64) créé par AMD, c'est que son architecture ne contient que 16 registres généraux (entiers et pointeurs), contre 32 pour ARM 64bits (AArch64).

Ça permet évidemment à nos Mac ARM d'émuler facilement les 16 registres du x86, mais en laisse beaucoup inutilisés, et je pense que Rosetta 2 en profite pour limiter les relectures après écriture dans la pile (les écritures étant probablement conservées).

Une autre optimisation peut être d'éliminer les copies de registres inutiles, puisque en ARM 64 bits les opérations ont souvent 3 opérandes (2 sources et 1 destination), contre 2 en x86 64 bits (1 source, 1 destination).
Par exemple a=b+c en x86 64 bits consiste à "copier" (créer un alias) b dans a puis à lui ajouter c (2 opérations), quand en ARM 64 bits, on ajoute b et c dans a en une seule opération.

L'aliasing de registres (ex-copie) est "gratuite" en x86 maintenant, mais nécessite de décoder une instruction de plus, donc plus de charge coté décodeur (front end) qui est déjà un problème en x86 avec des instructions de longueur variable et le travail pour créer les micro-instructions et macro-instructions depuis les Core™ 2.

Je vais vous revenir avec une comparaison avec du code ARM natif (même compilo mêmes options). Mais ce résultat est très surprenant, Apple fait un travail incroyable sur Rosetta 2 !

Réalisation ChatGPT 5.1, prompt pourri et déjaunissement par Philippe

Acte 1 : Le cloud privé Apple pour Siri avec des IA Google

Apple voudrait utiliser des IA Google pour Siri, dont des versions modifiées de Google Gemini voire Google Gemma.
Tout cela dans son "cloud privé", ce qui ne veut pas dire grand-chose.

Apple n'a pas encore les datacenter pour leurs propres IA cloud, et si des rumeurs indiquaient que de futurs M5 pourraient être des "compute module" pour cela, on est probablement à 1 ou 2 ans de leur implémentation à l'échelle de leur clientèle d'utilisateurs !

Mais où donc pourrait être alors hébergé le "cloud privé" d'Apple pour Siri?!?

Acte 2 : Google annonce son cloud privé sécurisé par TEE

La situation s'éclaire avec Google annonçant un "cloud privé sécurisé", dans ce cas des pool de serveurs au sein de ses propres datacenter, loués ou achetés par les clients l'utilisant pour faire tourner des IA, dont celles de Google: Gemini et/ou Gemma.

Le "cloud privé" d'Apple pour Siri pourrait bien n'être que des serveurs "privés sécurisés" chez Google.
La sécurité reposant sur plusieurs couches, dont la couche matérielle TEE.
Cette couche TEE devant théoriquement empêcher tout accès physique aux données présentes dans ces serveurs d'IA. C'est une protection contre l'accès physique aux données.

Google prétend que son "cloud privé sécurisé" serait aussi sécurisé que l'exécution locale.
Ça rassure, la sécurité est incroyable grâce aux TEE ! Ou pas?

Acte 3 : L'insécurité de TEE est prouvée

Et voilà que des chercheurs se sont intéressés au sujet, et ont littéralement démoli la couche de sécurité TEE, que les données soient stockées en DDR4 (déjà fait avant) ou en DDR5.
Et cela sur les 3 architectures CPU/SoC majeures. Toutes.

Les TEE de nVidia, AMD et Intel sont tous cassés. Le papier de recherche est ici (PDF).

Pas de protection d'accès physique, donc aucun "cloud privé", Google étant en mesure d'accéder aux données de ces serveurs d'IA dans son datacenter. Ou des agences Américaines.
À la merci de qui les exigera. Ou simplement pour récupérer nos échanges et nos vies...

Pour ceux qui veulent en savoir plus, c'est l'usage de chiffrements "déterministes" par réusage de clés qui est le problème, créant des possibilités d'attaques de type Replay.
On ne fait jamais ça, on ne doit jamais faire ça. C'est plus rapide, mais non... Jamais !

Même pas besoin que la NSA, comme d'hab, pourrisse la génération de clés pseudo-aléatoires en poussant des générateurs pas du tout aléatoires. AMD a mis 6 ans avant de reconnaître sa faute.
Un grand pas en avant qui simplifie tellement le travail des Agences Américaines !

Conclusion

Le "cloud privé sécurisé" dont Apple et Google se targuent n'est en rien sécurisé ou privé: je pense qu'ils foncent dans le mur, comme tout ceux qui croient à leurs promesses.

Il est à noter qu'il y a d'autres failles dans le modèle de "cloud privé sécurisé" de Google, puisque reposant sur des acteurs "indépendants", mais pas indépendants des Lois et Agences Américaines.
Même pas besoin d'accès physique ! Même pas besoin de failles de TEE ! Les lois US !

Mon avis est que si c'est dans le cloud, ça n'est ni sécurisé ni privé, c'est publique...
L'exception étant de contrôler le chiffrement et le déchiffrement localement, soi-même.
Et pour les IA, c'est localement avec LM Studio par exemple (et beaucoup de RAM).