Processeurs Skylake et Kaby Lake : un bug avec l'Hyper-Threading
Un des développeurs de Debian a mis en lumière un bug touchant la fonction Hyper-Threading des processeurs Intel de génération Skylake et Kaby Lake, ainsi que les Xeon v5 et v6.
Ce bug, qui concerne tous les systèmes d’exploitation, peut causer des erreurs, dont des pertes de données. En janvier, un développeur d’OCaml, une implémentation du langage de programmation Caml, disait avoir constaté des erreurs sur deux MacBook Pro 15" fin 2016 (Core i7–6820HQ).
La fonction Hyper-Threading, qui double virtuellement le nombre de cœurs pour augmenter les performances, est disponible sur les Core i7 ainsi que certains Core i5. Les Mac équipés de processeurs Skylake ou Kaby Lake avec Hyper-Threading sont les iMac Retina 5K Core i7 fin 2015 et 2017, ainsi que les MacBook Pro 2016 et 2017.
Intel a identifié le problème, mais il faut maintenant que les constructeurs publient une mise à jour du BIOS ou de l’EFI contenant les correctifs. Apple ne semble pas l’avoir fait pour le moment.
Si vous remarquez des bugs sur votre Mac qui fait partie de ceux concernés, vous pouvez désactiver l’Hyper-Threading en ouvrant l’application Instruments fournie avec Xcode (utilisez Spotlight pour l’ouvrir), puis en décochant « Hardware Multi-Threading » dans la section CPUs des préférences. Attention, l’Hyper-Threading se réactive après la mise en veille ou le redémarrage.
Je ne trouve pas l'application que vous citez avec Spotlight
Elle est sensé être localisé ou?
@fousfous
Avec Xcode je parie.
@bugman
oui, helas.
Helas, parce que seuls les developeur et "power user" ou bidouilleurs, vont ainsi pouvoir eviter les erreurs commises par le processeur mais en en degradant fortement les performances.
Je vais pas faire le pleonasme de denoncer la responsabilité d'Intel dans l'histoire, mais une petite explication s'impose.
Il y a 3 ecoles dans l'informatique:
1) considerer que la machine doit stupidement excuter le plus vite possible ce qu'on lui ordonne
2) considerer que la machine doit stupidement excuter le plus vite possible ce qu'on lui ordonne mais en offrant des outils d'optimisations sur les taches les plus automatiques
3) considerer que la machine est plus performante que le programmeur pour nombre de taches.
Les ecoles 1 et 2 font reposer l'efficacité sur la simplicité d'execution, la complexité devant etre resolue au niveau du programmeur et du compilateur, donc avant l'execution.
Avec le x86 Intel fait partie de la troiseme ecole, ce qui tombe bien, parce que le corollaire c'est que ça permet de mettre une grosse brique dans la construction d'un monopole.
Il y a 2 façons d'executer rapidement une tache informatique:
1) faire tourner le plus vite possible le moteur (on parle d'instructions par cycle sur un core)
2) decouper en sous taches que l'on repartie sur le maximum d'unités d'execution (on parle de nombre de core)
Avec les Pentium 3 et 4 Intel, qui jusque la ne jurait que par augmentation de la frequence du core (processeur monocore), a atteint un mur, celui des 4Ghz. Augmenter la frequence faisait alors exploser le degagement thermique de maniere ingerable.
La solution a alors ete de diviser la "charge" du processeur en le dedoublant (dual core). Le core pouvait alors tourner moins vite, donc moins chauffer, mais comme il y en avait 2, ça executait le double d'instructions par cylce. En theorie.
Le hic, c'est le x86 est une machine virtuelle CISC, vraiment tres compliquée. Lorsqu'un programmeur crée un programme, le code arrivant au processeur n'est pas executable, il faut qu'un premier etage dedié du processeur decode, decoupe, ordonne et encode les instructions complexes CISC en instructions que le moteur RISC peut executer . En retour, le resultat doit entre a son tour encoder en instuctions compatibles avec le jeu d'instructions CISC.
A ce processus s'ajoute des divergences de vitesse entre les différentes mémoires (RAM, cache, registres,...) qui font que par moment le core est surchargé et a d'autres il tourne a vide.
Pour reduire ce probleme, Intel a installer des etages de "pipeline" qui doivent en principe faire en sorte que le core ait toujours des instructions a traiter. Le code est ainsi excecuté dans un ordre decidé par le processeur, donc a l'execution.
Avec la multiplication des core le probleme de l'alimentation du core a ete augmenté: il ne faut plus alimenter un core, mais plusieurs, et eviter qu'ils tournent a vide.
La majorité des soft en micro-informatique sont séquentiels (ils s'executent sur un seul core). Il faut donc les "paralleliser" pour tirer partie des core presents.
Et la Intel a realisé tout un tas de strategies, plus ou moins efficaces, avec une en particulier: la virtualisation des core: l 'Hyper-threading.
En theorie virtualiser les core permet de gagner 30% d'efficacité. Mais cela est variable selon l'usage, les programmes et la mecanique du truc. Au pire cela peut ralentir l’exécution. Autre probleme l'hyperthreading depend beaucoup de la memoire cache. Donc un processeur "hyperthreadé" a interet a avoir de tres gros caches.
Si on desactive l'hyperthreading d'un processeur, il faut s'attendre a voir dans la majorité des cas une grosse perte de performances.
En l'occurence l'hyperthreading est tres performant avec des softs utilisé dans les traitment video lourd ou les gros calculs paralellisables.
Desactiver l'hyperthreading d'un core i7, va tres probablement le ramener a des performances inferieures a celles d'un Core i5 de frequence egale.
Bon ça vaut mieux que d'avoir des erreurs multiples et des corruptions de memoire qui affectent la machine entiere.
@C1rc3@0rc
"!Le hic, c'est le x86 est une machine virtuelle CISC, vraiment tres compliquée. Lorsqu'un programmeur crée un programme, le code arrivant au processeur n'est pas executable, il faut qu'un premier etage dedié du processeur decode, decoupe, ordonne et encode les instructions complexes CISC en instructions que le moteur RISC peut executer ."
le x86 n'est pas une machine virtuel, c'est un ISA (Instruction Set Architecture).
Les instructions sont CISC, ok, c'est ensuite decodé en micro ops, et ca part dans le pipeline.
Sur ARM, les instructions sont RISC, elle sont également décodé en micro ops avant de partir dans le pipeline.
Même chose, ok le decodeur va être plus complexe sur x86, mais en contre partie tu as besoin de moins d'instructions pour faire la meme chose, donc tu as plus de place dans les caches L1, L2, L3, et tu as besoin de moins de bande passante.
"En retour, le resultat doit entre a son tour encoder en instuctions compatibles avec le jeu d'instructions CISC."
Tu sais qu'un CPU ne produit pas d'instruction mais exécute des instructions, la seul chose qui sort d'un CPU c'est des écritures mémoire. Je ne sais pas d'ou tu sors ton encodeur d'instruction dans le CPU.
Une bonne reference sur les processeurs moderne :
http://www.lighterra.com/papers/modernmicroprocessors/
Étonnant, je n'ai a aucun moment évoqué ARM, ou eme une autre architecture et hop il arrive comme piece principale de ton argumentaire.
Marrant de voir que maintenant il n'est meme plus question de contester le fait qu'ARM soit une alternative credible au x86, c'est un fait ;)
«le x86 n'est pas une machine virtuel, c'est un ISA»
Mais si c'est bien une machine virtuelle, on programme une architecture virtuelle, d'ailleurs c'est meme un modele virtuel, puisque le modele x86 est purement SISD et que l'execution peut s'effectuer sur des unités SIMD, et les techniques de parallélisations aboutissent a du MIMD, voire du SIMT.
Sinon, tu consideres Java comme une ISA?
«Même chose, ok le decodeur va être plus complexe sur x86, mais en contre partie tu as besoin de moins d'instructions pour faire la meme chose»
Ben deja tu contredis ton argumentaire et en plus c'est un argument datant des annees 70 ou les programmes etaient ecrits en assembleur.
Avoir un jeu d'instructions complexes permettaient a l'epoque de simplifier la vie du programmeur et d'accellerer certains enchainements recurrents... mais ça vaut pour les 8086 de l'epoque.
Depuis un moment (et les architecture RISC n'y sont pas pour rien) les compilateurs sont capables d'analyser et cartographier l'ensemble du programme pour optimiser le code machine a produire. De plus on a des librairies, excecutables, ou les algorithmes sont hyper optimisés pour une architecture precise.
Aujourd'hui, le programmeur ecrit du code a un niveau d'abstraction de plus en plus elevé, et les compilateurs sont capables de produire de faire des simulation sur le code executable (pour chercher des fuite de memoire par exemple). Plus le compilateur va avoir un code executable simple et previsible plus le soft sera optimisé et securisé.
Donc avoir de longues instructions bien compliquées a la CISC ne sert qu'a perdre du temps de traitement.
«Tu sais qu'un CPU ne produit pas d'instruction mais exécute des instructions»
Moais le terme etait mal choisi, je te l'accorde. Ce que je voulais dire c'est qu'il faut convertir les données traitées par les architectures reelles sous jacentes en données compatible avec l'architectures x86, seule garantie de la sacro-sainte compatibilité ascendante avec les antique x86.
Encore que, l'architecture alambiqué des x86 pourraient reserver des suprises...
C'est un secret industriel d'Intel et il est difficile de verifier jusqu'a quel niveau se situe la virtualisation, mais en principe 2 thread cooperants doivent translater les donnees qu'ils s'echangent dans un format compatible avec le modele virtuel x86: representation interne A => representation externe => representation interne B. Mais c'est vrament technique et sujet a grosses discussions, Intel cachant evidement ce genre d'informations.
@C1rc3@0rc
"Étonnant, je n'ai a aucun moment évoqué ARM, ou eme une autre architecture et hop il arrive comme piece principale de ton argumentaire."
J'ai pris ARM comme example, c'est l'architecture "RISC" la plus repandue. On peut trouver plein d'exemple de CPU, c'est bien pour comparer ;)
"Marrant de voir que maintenant il n'est meme plus question de contester le fait qu'ARM soit une alternative credible au x86, c'est un fait ;)"
Crédible comment ? Crédible sur mobile oui, crédible pour netbook oui, crédible pour latptop non, crédible pour desktop non, crédible pour workstation non, crédible pour serveur non.
Et pourquoi crédible ou non, bah il suffit de regarder les processeurs ARM dispo, il n'y a pour le moment rien de crédible pour laptop, desktop etc... C'est un fait. Est ce que c'est du a l'architecture ARM, non, c'est une question de marché ciblé tout simplement.
Le switch apple de powerpc vers x86 est l'illustration que l'ISA n'avait pas vraiment d'importance, mais que le design du CPU est plus important.
"Mais si c'est bien une machine virtuelle, on programme une architecture virtuelle, d'ailleurs c'est meme un modele virtuel, puisque le modele x86 est purement SISD et que l'execution peut s'effectuer sur des unités SIMD, et les techniques de parallélisations aboutissent a du MIMD, voire du SIMT."
Non tu programmes pour x86 ou pour ARM, après ce que fait le CPU ca se passe dans le CPU, le SIMD c'est du CISC, tu rajoutes des instructions pour de nouvelle fonction.
"Sinon, tu consideres Java comme une ISA?"
Java est un language...
"Ben deja tu contredis ton argumentaire et en plus c'est un argument datant des annees 70 ou les programmes etaient ecrits en assembleur."
Non tu n'as pas compris mon argument, tu as moins d'instructions donc ca prends moins de place dans le cache d'instruction, et dans les autres caches, ce qui veut dire que tu as plus de bande passante. Donc tu as un decodeur plus complexe dans le cas du x86, mais tu as aussi l'avantage d'avoir moins d'instruction dans les caches.
"Donc avoir de longues instructions bien compliquées a la CISC ne sert qu'a perdre du temps de traitement."
Euh, ben justement elle sont decodé en micro ops, donc aucune importance.
"Aujourd'hui, le programmeur ecrit du code a un niveau d'abstraction de plus en plus elevé, et les compilateurs sont capables de produire de faire des simulation sur le code executable (pour chercher des fuite de memoire par exemple). Plus le compilateur va avoir un code executable simple et previsible plus le soft sera optimisé et securisé."
j'écris toujours en C++, et ca crache toujours du x86, et la plupart des compilos continuent a cracher du x86 ou dy bytecode pour des languages de type java.
Oui les mecs qui ecrivent les compilos font des progres, yeah!!!!
"les données traitées par les architectures reelles sous jacentes en données compatible avec l'architectures x86"
Euh, c'est quoi le délire la, un cpu ca traite des int ou du floating point. Et ensuite tu ecrits des bytes en memoire, super compliqué... il n'y a rien a convertir.
"Encore que, l'architecture alambiqué des x86 pourraient reserver des suprises..."
Tu parles de quoi de l'ISA ou des cpu Intel ou AMD ?
Ca fait 20 ans que l'on enterre le x86, et ca fait 20 ans qu'il n'a pas d'alternative autre que sur le mobile avec ARM. Si il y a vait vraiment une faille majeure dans le x86 ca fait longtemps que l'on aurait atteint les limites.
Des quelle surprises tu parles ?
Y'a un biais "monopole Wintel" dans l'opinion de @C1rc3@0rc sur les CPU d'Intel.
Ce qui semble à ses yeux interdire le moins attrait technologique aux CPU d'Intel...
Ironiquement, y'a probablement jamais eu autant de CPU Intel ne fonctionnant *pas* sous Windows de nos jours comparé aux années 90...
@Stardustxxx
tu devrais laisser tomber
@C1rc3@0rc
"Intel"
?♂️?♂️
@fte
Ça m'aurait étonné qu'on n'ait pas droit à sa (longue) diatribe sur Intel... ?
@fousfous
Suivez le guide.
Xcode installé ?
Command line tools aussi ?
Dans ma version : Xcode -> Open Developer Tool->Instruments.
Pour plus :
https://gist.github.com/loderunner/36724cc9ee8db66db305
ensuite
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/index.html#//apple_ref/doc/uid/TP40004652-CH3-SW1
@occam
Ah bah non j'ai pas Xcode, il faudrait le préciser du coup.
L'hyper threading est aussi actif sur les i3 et depuis peu sur certains Pentium (je chipote)
Vous faites mal au crâne les gars
@ecosmeri
Grave...
Lol, ouais. Totalement.