Ces derniers mois, Intel a longuement évoqué ses plans pour les années à venir, l'évolution de sa finesse de gravure ou du packaging de ses processeurs, permettant leur plus grande modularité. Le géant de Santa Clara a détaillé certains points à l'IEEE International Electron Devices Meeting (IEDM) 2021.
Si Alder Lake-S est le premier véritable CPU hybride mis sur le marché par Intel, avec des cœurs différents au sein d'une même puce, c'est loin d'être la seule initiative qui vise à revoir en profondeur les processeurs de l'entreprise.
Les processeurs LEGO : une tendance qui va s'accentuer
En effet, les années à venir vont être l'occasion pour l'entreprise de multiplier les petits pas allant vers des ensembles très modulaires, avec une diversité de puces reliées entre elles, pouvant être conçues et fabriquées par Intel ou non. De Sapphire Rapids à Granite Rapids en passant par Meteor Lake et Ponte Vecchio, tous participeront à cet effort. Ajoutons à cela les travaux menés dans la photonique via un nouveau laboratoire et le projet Lightbender.
À l'occasion de l'IEDM 2021, Intel est revenu sur certaines des technologies qu'il développe actuellement dans ce but. C'est notamment le cas de Foveros Direct, qui doit prendre la suite de Foveros avec une meilleure densité et donc une réduction de l'espace nécessaire pour la communication entre différents chiplets, les débits n'étant pas précisés.
Cette solution doit également permettre selon Intel la multiplication de puces diverses, en termes d'objectif ou de dimensions, au sein d'un même processeur, avec une organisation qui tiendra un peu du Tetris :
Stacking, GaN, Quantique : des buzzwords pour vanter la recherche
Dans une seconde vidéo, Marko Radosavljevic évoque le passage aux RibbonFET qui arrive sur les processus de prochaine génération (20A) avec un stacking permettant là aussi de réduire l'espace nécessaire, via différentes solutions testées depuis 2019. Mais aussi l'introduction du Nitrure de Gallium (GaN).
L'équipe dit aussi travailler à des solutions exploitant des concepts de la physique quantique lorsqu'il s'agit de remplacer les actuels transistors, avec des composants MagnetoElectric Spin-Orbit (MESO) fonctionnant à une température classique devant permettre d'aller encore plus bas dans la finesse des processus de fabrication.
Intel s'est d'ailleurs associé à IMEC en la matière, montrant le processus de fabrication qui pourrait être utilisé pour des solutions de calcul quantique sur des wafers de 300 mm. Mais là aussi il s'agit de promesses un peu vagues. Il faudra sans doute attendre que ces projets avancent pour avoir droit à des notions plus concrètes.
Commentaires (32)
#1
Comme dans les années 80, Intel doit se battre pour survivre à la montée en puissance l’architecture Risc.
Comme l’histoire se répètera à nouveau, Intel y perdra beaucoup beaucoup de sa superbe…. pour laisser la place (à Apple sIlicon ???)
#2
Oui enfin à échéance 2025, RISC n’est pas vraiment un souci pour Intel ou la motivation de ces projets (qui sortent de terre donc sont en travail depuis un lmoment ;)) Pour le reste, ceux qui sont attentifs auront noté que l’intérêt de la modularité c’est aussi de pouvoir en finir avec des approches monothéistes.
#3
L’industrie a une inertie énorme dont Intel profite très largement. Déjà que l’industrie ne s’est pas détournée d’Intel malgré la conso électrique et un certain retard par rapport à AMD, passer à une architecture radicalement différente prendrait une bonne dizaine d’années, au moins.
Si on regarde la grosse mode du moment, les containers, 99% des images de container tournent sur x86_64. C’est impensable dans un délai court de tout faire passer en ARM ou Risc-V.
Ça n’est pas parce qu’AWS, Alibaba et Google font tourner certains de leurs logiciels sur ARM que ça va immédiatement débarquer partout.
#4
il va falloir m’expliquer aussi ou est la plus value d’arm !
les macbook avec apple M1 offre une bonne autonomie et une bonne puissance mais c’est cher.
pour 900€ on trouve des portables x86 qui atteigne le même niveau de perf et d’autonomie
pour le reste… les puces arm sur serveurs sont plus cher, aussi énergivore et moins performante que les proc d’intel/amd.
je ne vois aucun gain a utiliser un cpu arm ampere sur un serveur.
les pc portable atrm sous des soc arm qualcomm c’est de la grosse merde et très cher ! un portable avec un pentium à 300€ le dépasse.
arm est bien positionner sur les puces bas de gamme, peu performante mais surtout peu consommatrice, comme sur le raspberry, intel n’a aucune solution sur ces segments.
je me souviens des smartphones sous intel atom, ils étaient aussi bon a l’époque que des qualcomm haut de gamme.
si demain vous me proposé de l’arm pas cher et plus puissant que les solutions d’intel/amd, oui pourquoi pas changer. je suis convaincue qu’une puce mobile intel moderne arriverait facilement a égaler le snapdragon 8 gen 1 au niveau du ratio conso/perf.
#5
la vérité c’est qu’un cpu arm moyen/hauyt de gamme sa coute aussi cher a produire qu’un cpu intel/amd.
des qu’on veut de la puissance et donc qu’on augmente la fréquence, arm sa chauffe et sa consomme autant que du x86, y’a pas de magie.
la grosse faiblesse d’intel/amd c’est leur incapacité à produire des petite puces x86 à 10-20€ pour de l’embarqué
#6
Je ne vois pas Apple Silicon devenir le leader sur PC, pour la simple raison qu’Apple ne vend pas sa puce à des intégrateurs tiers.
#7
Vous avez regardé des tests des Macbook avec Apple Silicon ? Parce que bon, la conclusion N°1 de l’ensemble des tests depuis la sortie des puces c’est justement que lancé à pleine puissance, ça consomme très peu par rapport à Intel (de la génération précédente, certes). Les portables ne chauffent pas et ont des capacités de calcul supérieures à leurs équivalent Intel.
Pour le prix, difficile de se prononcer : à ma connaissance, pas de prix révélé pour les processeurs Qualcomm pour Windows on ARM, et pas de vente externe pour Apple. Par contre le prix des portables Apple n’a pas bougé à gamme équivalente (Macbook Air à 1000€, Macbook Pro de base à 1500€, Macbook Pro 16” à 2700€). Conclure sur la marge d’Apple sur ce point me paraît difficile.
Multiplier les cœurs et les puces sur un même SoC en optimisant l’intégration semble une bonne réponse d’Intel. Et ils vont s’appuyer sur 10 ans de travaux de R&D chez l’IMEC ou le CEA Leti. Assumer de ne plus pouvoir rester leader s’en s’ouvrir à la concurrence européenne et taïwanaise est probablement la meilleure façon de le rester de nombreuses années.
#8
C’est le problème quand tu ne paies pas les produits, tu peux vite oublier que le prix est l’un des problèmes essentiels lorsqu’il s’agit pour une technologie de se démocratiser.
Les M1 sont des CPU efficaces, mais conçus et commercialisés par Apple, donc visant une part mineure du marché et disposant d’un atout : l’écosystème est contraint, plutôt fermé, donc nécessitant un support limité, ce qui permet d’aller vite sur certains aspects.
Ce qu’ils nous apprennent, c’est qu’avec la gravure de TSMC, on peut faire mieux. Reste à voir comment ceux qui ne visent pas une “élite” se limitant à un écosystème en bonne partie fermée s’aligneront dans les mois et années à venir. Mais les mouvements constatés ne sont pas ceux d’un acteur en particulier.
La modularité, le stacking, l’hybridation & co sont un travail de fond de l’industrie dans son ensemble depuis des années. Cela aboutit plus ou moins vite selon les acteurs, mais c’est le sens de l’histoire. Et quant à savoir qui est “leader” tout dépend de quels secteurs ont parle. On sait que ceux du jour ne sont pas ceux de demain. L’important pour un acteur c’est de savoir se renouveler, dans les bonnes comme dans les mauvaises périodes… qui finissent toujours par survenir.
#9
c’est tous le probleme justement, c’est pas comparable !
le M1 bénéficie d’une gravure plus fine ainsi que d’un écosystème ultra fermé et donc ont peut plus facilement optimiser sont code.
cependant pour être un minimum objectif comparons avec la dernière génération d’intel, gravé en 10nm et avec ces cœurs hybride.
le meilleur modèle d’alder lake mobile est plus puissant que le M1 (avec une consommation légèrement supérieure)
donc x86 ou arm c’est pareil niveau perf, je ne pense pas que l’un des 2 arrivera a surpasser l’autre dans le futur.
après reste le point le plus important: le prix
les solutions arm sur pc portable sont très très cher, que ce soit apple ou qualcomm.
#10
Je pense au contraire qu’un écosystème fermé permet moins d’optimisation qu’un écosystème ouvert, où plusieurs compilateurs peuvent être développés et se concurrencer.
#11
Il est mille fois plus aisé d’optimiser un système conçu pour fonctionner étroitement avec un matériel précis, et surtout l’inverse est possible aussi, d’optimiser le matériel en fonction du comportement voulu côté système.
Je suis d’accord avec le fait que la concurrence permet une évolution des optimisations, mais elle ne pourra jamais atteindre ce que le développement croisé du matériel et du logiciel permet.
#12
Tout dépend du contexte. Ce qui est important c’est le nombre et la compétence de ceux qui travaillent sur les compilateurs.
Tu peux avoir une société qui fait tout son matos de A a Z et qui met quasiment pas de devs sur l’optimisation, et par conséquent l’optimisation sera mauvaise.
Tu peux avoir un projet open-hardware peux soutenu, le résultat sera le même.
Dans le cas d’apple, quand on voit les résultats de rosetta, on ne peux que se dire qu’ils ont mit le paquet sur les devs.
#13
Là dessus, je ne peux que te contredire. En développant, un environnement spécifique peut fournir des fonctionnalité spécifique qui seront bien plus efficace qu’un code générique mais en contre partie peuvent demander des prérequis différents.
Beaucoup d’optimisation ne peuvent donc pas être fait automatiquement par un compilo (ou une quelconque machine), et, dans le cadre d’un environnement ouvert, si tu veux faire de l’optimisation il faut bien souvent réécrire autant de fois les partie optimisables que le nombre d’environnement que tu veux optimiser.
Par exemple, VLC en plus d’un code générique, possède du code assembleur spécifique aux plateformes les plus courantes.
#14
Ben un compilo est conçu pour fonctionner avec un matériel précis. Et la plateforme x86 est assez connue et on sait optimiser pour.
Ce à quoi tu penses à mon avis, c’est le fait que c’est plus facile pour Apple d’avoir un système solide parce qu’ils n’ont pas le problèmes de drivers (écrits par eux ou pas, généralement pas) pour des myriades de matériels, là où dans une plateforme Microsoft le matériel est pléthorique, et les drivers de qualité variable. Et comme clairement Microsoft n’est pas super bon en développement, depuis le début (finalement, ça ne s’est jamais tellement amélioré, même si le système est plus stable).
La fabricants de CPU font déjà le boulot de proposer régulièrement des extensions (nouvelles instructions en ce sens), ou d’optimiser en fonction des charges constatées sur des OS et logiciels courants.
A moyens égaux consacrés au développement (et mine de rien côté Linux c’est pas mal au total), je ne pense pas qu’Apple fasse vraiment mieux sur son matos que les devs Linux sur du x86 (qui est bien maîtrisé).
Le code n’est pas vraiment générique, si on parle par ex du code d’un Linux compilé pour une plateforme x86 (ou d’autres un peu courantes). Sans parler du fait qu’il existe toujours quelques bouts en assembleur parce que ça vaut le coup d’y passer un peu de temps pour une belle optimisation.
Justement, c’est ce qu’on fait toujours (pour les projets un peu importants), tu as cité le cas typique de VLC, mais ce n’est pas le seul.
#15
Effectivement, mais pas du tout dans les mêmes délais…
#16
La théorie du x86 oui. La réalité c’est qu’il existe un nombre incalculable de cartes mères, processeurs, mémoires vives et périphériques qui rendent le nombre de configurations possible encore plus dingue. Et chacune de ces pièces y va de sa petite particularité.
Si on devait optimiser pour chacun de ces cas, on aurait pas assez d’un milliers de vies. Apple lui, peut se le permettre.
j’ai cent fois plus de respect pour Microsoft et la communauté du libre pour réussir à faire tourner leurs systèmes sur autant de plateformes différentes. Facile de dire qu’Apple travaille mieux quand justement leur support matériel est extrêmement restreint et demande très peu d’énergie de leur part (par rapport aux deux autres).
Et on voit bien ce qu’il se passe quand on tente d’optimiser pour un produit en particulier : l’update du scheduler Windows pour les derniers Intel a flingué les performances des AMD. On ne peut pas optimiser à 100% pour un produit sur un système qui se doit d’être le plus généraliste possible.
Si à moyen égaux Apple ne fait pas mieux sur sa plateforme que Linux sur du x86 c’est qu’ils ont un gros problème. Entre faire un effort pour soutenir une dizaine de variations de plateformes et de l’autre un nombre théorique infinie, je voit pas comment le deuxième peut faire mieux avec les mêmes moyens.
Oui en théorie on peut optimiser finement sur une plateforme ouverte. Oui Apple peut très bien faire n’importe quoi avec son matos. Mais la vérité c’est qu’Apple bosse un minimum correctement en développant ses produits avec un budget conséquent. Microsoft et le libre ne pourront égaler cette force de frappe.
C’est aussi pour ça que j’aime pas les comparaisons entre le matériel Apple et le reste. Ouais cool le M1 fait X fois mieux, mais dans des conditions où rien n’est équivalent.
#17
Si tu parles du monde x86, les processeurs sont de la même famille avec le même jeu d’instruction, et sauf pour des générations très éloignées, les optimisations sont grosso modo les mêmes. Pour le reste (CM, mémoire vive, périphérique), je ne vois pas bien en quoi ça influe l’optimisation sur CPU.
En l’occurrence, jusque récemment, Apple devait optimiser pour la même architecture x86 que Microsoft et Linux.
Ben là on parle de bas niveau, là où on a encore des bouts d’assembleur, et où il y a des différences d’archi entre familles (Intel et AMD).
Là où Apple est plus fort que Microsoft c’est sur l’optimisation sur la consommation (et donc autonomie) à plateforme x86 équivalente, et là il est question en particulier d’optimisation des drivers.
Microsoft a des moyens gigantesques, et quand on voit le résultat… C’est très décevant.
#18
Les sets d’instructions ne sont pas identiques. Tu as des nouveautés selon les générations, des spécificités selon la gamme (AVX 512 par ex) etc… Et puis tu as les différences plus flagrantes comme le nombre de coeurs, la fréquence ou la quantité de mémoire embarquée.
Le chipset amène des restrictions ou des possibilités, l’étage d’alimentation permet de maintenir plus ou moins bien de hautes fréquences, la RAM a une fréquence et une latence variable etc… Un processeur sans rien autour ça n’accomplit pas grand chose.
Mais sur des matériels choisis et limités. Mac OS ne tourne que sur leurs appareils et ne fonctionne pas sur les autres, il suffit de regarder les Hackintosh. Les gens qui s’y lancent doivent chercher le matériel le plus proche de l’existant Apple et c’est loin d’être sans défaut.
je vois pas ce que l’assembleur ou n’importe quel autre langage dédouane dans tout cela. L’optimisation ça se fait à tout les niveaux. Pour faire une voiture économe on va pas se contenter de prendre un gros moteur et l’utiliser à la moitié de sa puissance. Ici c’est pareil. Apple peut se permettre de développer un processeur qui colle à 100% à son cahier des charges logiciel en s’assurant que la plateforme a le comportement voulu lorsqu’ils utilisent tel fonctionnalité (consommer un minimum ou avoir le maximum de perf). Ils vont aussi penser à tout ce qui entoure le CPU : alimentation calculée au plus près, RAM à la fréquence/latence idéale pour communiquer avec ce proco précis… Pour Windows et Linux c’est l’inverse, c’est la plateforme qui dicte son cahier des charges (je fonctionne comme ça, si vous faites çi je fait ça).
Parce que les plateformes ne sont pas équivalentes. Apple choisit très précisément ses composants et travaille très en amont avec les fabricants (rappel qu’Intel a fait notamment une gamme sur demande d’Apple, les Kaby-Lake G). Microsoft se doit de faire fonctionner son système partout (rappel² qu’il y a une grosse pression des entreprises sur Microsoft car ils ne veulent pas changer tout leurs parcs à chaque grosse mise à jour ou parce qu’ils ont des machines outils ancestrales qui doivent fonctionner encore des dizaines d’années).
Un OS qui tourne sur plus de 90% du parc mondial, aussi diversifié que la population humaine et souvent des machines âgées.
Y’a beaucoup à dire sur MS et son système mais dire “Apple y arrive en claquant des doigts, MS devrait y arriver aussi en claquant des doigts” ce n’est pas rationnel. On parle peut-être de pouillième à gauche et à droite, mais pleins de pouillièmes, ça commence à faire une sacré marge au final.
#19
S’il faut faire du code spécifique à chaque environnement, c’est donc plus difficile de faire du code optimisé.
Pour donner l’exemple que je suis souvent confronter, c’est le calculs sur des arrays/vector/tensor (c’est plus ou moins la même chose). Soit je le fait de manière 100% CPU façon old-school en faisant des boucles case par case. Ce code sera sans problème compatible avec n’importe quel porcesseur, X86, ARM, PowerPC Risk-V…. mais sera aussi très inefficace.
Les processeurs x86/x64 intégres les instructions SSE de 1 à 5 (de 1999 à 2011) qui sont fait pour ce genre de calculs. Les processeur Intel et AMD intégre aussi les instructions en plus AVX et AVX-2. Cependant, seul quelque processeur récent d’Intel possèdent les instructions AVX-512 encore meilleurs. Mais voilà, ça encore, c’est de la merde quand il faut faire des tableaux contenant des millions des valeurs, les cartes graphiques sont justement, par leur design, construites pour faire des calculs sur des tableaux et dépasse les CPU si le temps de chargement de la mémoire et de déchargement en valent le coup. Il existe bien la bibliothèque OpenCL mais on va se l’avouer, elle n’est pas beaucoup utilisé. En effet, sur le calculs sur carte graphique, c’est NVidia qui possède le marché, et ses bibliothèque Cuda compatible avec uniquement les cartes graphique NVidia (et selon les versions CG/lib aussi). Il y a bien AMD qui essaie un truc avec RocM mais ça n’a pas vraiment la maturité de Cuda. Derrière, il y a Intel qui propose OneAPI pour concilier tout le monde, mais ça sent surtout la solution moyenne en tous car chaque cas doit être pensé individuellement (parfois le CPU est meilleur).
#20
et chez Apple ils autorisent que metal…
pour ton probleme de sse et avx, tu as ce probleme partout !
Apple va obligatoirement dans le futur ajouter de nouvelle instructions à ces cpu M, si tu veux les utiliser elles ne serons pas utilisable sur les anciens modèles.
Ce probleme va se poser des maintenant d’ailleurs, ta futur application android/ios, tu vas devoir la compiler en arm v7 ou v8 (qui vient juste de sortir).
les solutions pour ton probleme c’est:
Porter une application sur un autre système c’est du travail. Beaucoup de jeux videos par soucis de rentabilité on des portages foireux
#21
Mais à part des questions spécialisées comme les instructions AVX de nouvelle génération, l’optimisation d’un système c’est bien plus généraliste que ça, et ça ne dépend pas du nombre de coeurs, encore moins de la fréquence ; à la rigueur la taille des caches internes peut jouer sur l’écriture de l’algo, mais là aussi on ça implique des cas particuliers comme le calcul numérique et la multiplication de matrices.
Ça sort de la question initiale (“Apple peut mieux optimiser”).
En quoi ça va changer le code pour l’optimisation des perfs ?
Éventuellement, il y a un bout de code dans l’OS, dépendant de la variante du processeur, pour optimiser la consommation quand on est dans le domaine du portable. A noter que les processeurs eux-mêmes ont des mécanismes pour communiquer avec l’OS pour améliorer la question.
Dans Linux typiquement une grosse partie du code est assez générique et il y a des bouts pour optimiser (côté rapidité ou conso) sur certaines architectures ou certains processeurs. Mais les recompilations de noyau en indiquant à gcc qu’on est sur tel processeur précis, ça augmente peu les performances (cf essais de Phoronix).
C’est plutôt une question de drivers ça. En fait on en revient aux drivers pour l’optimisation de la consommation.
Je me souviens que quand on peut installer MacOS et Windows sur le même matériel portable, l’autonomie est sensiblement meilleure pour MacOS. Pour les perfs générales je ne sais plus, mais je ne serais pas étonné qu’idem.
Bien sûr, ça commence par le choix des algorithmes. J’ai eu à optimiser du code de ce point de vue-là (exemple classique : choix d’un algo de tri adapté à la situation).
Dans Linux il y a eu plusieurs fois de belles améliorations d’algo, par exemple quand le scheduler est passé en complexité constante ( O(1) ), ou sur la création de milliers de threads (ça date à présent). Ils ont fait aussi des améliorations sur les files d’I/O, avec les multi-queues.
Quand tu utilises un logiciel lambda sur un Mac, il n’est pas forcément écrit par Apple, par exemple les Lightroom et autres, ou l’application de bureautique de MS. Le truc avec lequel je suis d’accord c’est qu’Apple contrôle mieux les drivers et peut optimiser l’autonomie.
Remarque idem à ci-dessus.
Oui mais je rappelle que les fabricants de CPU optimisent aussi leurs CPU pour être efficaces (énergie et rapidité) sur le code déjà déployé. C’est leur intérêt.
Pour ma part je n’ai pas dit “en claquant des doigts”, vu que c’est un boulot précis.
Bon on a sans doute quelques points d’accord et d’autres de désaccord.
#22
Comme dit dans mon commentaire juste au-dessus, ça dépend si on parle d’optimisation de perfs ou de consommation (ça peut être lié certes). Il y a aussi l’aspect micro-optimisation, qui ne se sent pas beaucoup en usage courant, hors usage spécial.
T’es parti sur le calcul numérique mais c’est un tout autre sujet (que je connais un peu sans être expert, j’ai déjà fait joujou avec le SSE), bien plus spécifique que l’optimisation générale d’un OS, en terme de perfs ou de conso.
#23
Le jeu d’instruction d’ARM est plus efficace que celui d’Intel. Pour un même procédé de fabrication, grace au jeu d’instruction, la micro architecture sera plus simple et moins énergivore sur ARM. ARM permet de concevoir des puces plus puissantes que celles d’Intel, encore faut-il s’en donner les moyers.
Pour le reste, ça doit faire 20 ans que j’entends parler de modularité… RAS, Intel essaye juste de rassurer sa clique et fait du bullet points.
#24
Les instructions ARM ne sont pas plus efficaces, elles sont moins nombreuses et pensées différemment. ARM est une architecture RISC, qui va favoriser les instructions simples mais travaillant sur un grand registre. le x86 est une archi CISC, qui dispose d’un plus grand nombre d’instructions et certaines complexes mais va se permettre d’éviter de travailler en mémoire.
Le problème (et la force, dépend du résultat voulu) de l’ARM aussi est de permettre des architectures personnalisées avec des jeux d’instructions personnalisés aussi. Un processeur Qualcomm ne fonctionnera pas comme un Samsung ou un Apple du fait de leurs instructions différentes, même si ils utilisent la même version de l’architecture. C’est un bonheur pour le fabricant qui va pouvoir avoir un matériel qui synergise au maximum avec le système, c’est un casse-tête pour le développeur qui veut développer pour ces trois plateformes qui semblent pourtant si proches.
#25
Les instructions spécialisées d’aujourd’hui sont le standard de demain. Si on les développe, c’est qu’il y a un besoin suffisamment important pour les populariser.
ça dépend de ton algo. Tu peux avoir un algo multithreadé correct mais tu te rends compte que, sur ce proco faiblement threadé et avec une très haute fréquence, tu aurais tout intérêt à le faire d’un seul thread.
Ca change ta façon d’appréhender ton scheduler. Tu sais que ton processeur réagit mal au delà d’un certain temps à haute fréquence donc tu mets des contre-mesures pour les minimiser. Ou bien tu sais à quelle fréquence faire tourner ton CPU pour tirer au minimum sur l’étage d’alimentation et rester sous le seuil de chauffe pour le ventilo, et donc économiser la batterie.
C’est une suite de petits détails qui s’additionne.
Les drivers ont bon dos. Le système n’est pas fait pour tourner sur ce matériel et ne sait pas agir correctement car pas optimisé.
Certes mais développer pour un système plus opti comme Mac OS permet aussi de pousser l’optimisation plus loin si on le souhaite. A un niveau bien plus haut donc pas forcément aussi pertinent mais Adobe pourrait tout à fait décider d’optimiser sur Apple car il y a beaucoup moins de cas à gérer que Windows.
Tout à fait, mais ça ne sera jamais aussi efficace que lorsqu’il s’agit d’une seule et même entreprise.
Tout le monde peut optimiser son logiciel pour la plateforme de son choix, je dis juste qu’Apple a des facilités au regard de son contrôle sur le logiciel et le matériel :)
#26
Non il a raison, l’architecture ARM est plus efficace, ce qui n’est pas difficile étant tout l’historique de l’archi x86. Ces derniers sont puissants, mais avec quelle “débauche” de transistors. L’ironie c’est aussi que le coeur des x86 est du type RISC avec la traduction en interne en micro-opérations.
Et l’efficacité fait que l’archi x86 n’a pas franchement percé dans le domaine mobile.
Je ne te suis pas sur la fin de ta phrase. En quoi le RISC travaille plus en mémoire ? Historiquement, les CPU RISC ont plus de registres, en plus.
#27
Je me demande quel pourcentage d’utilisateurs bénéficie vraiment des instructions type SSE/AVX ; à mon avis pas tellement, vu l’usage moyen d’un ordinateur.
En revanche, pour du calcul numérique, ou du traitement d’image un peu parallélisable, c’est intéressant. Cela dit, j’ai lu que le AVX posait des problèmes de consommation, et qu’il y avait un facteur multiplicateur inférieur quand un coeur faisait de l’AVX à plein temps.
C’est plausible mais un logiciel bien fait permet de tester (ou d’être configuré) entre du mono-fil et du multi ; sans recompilation je veux dire.
Là on est dans l’autonomie, après comme je disais, l’échange entre l’OS et le CPU peut être en partie générique ; le principe que tu indiques vaut pour à peu près tous les CPU modernes.
Non non, ils sont en cause sur l’autonomie, c’était bien expliqué justement dans un article un peu technique lu il y a des années, concernant les Mac. De mémoire, c’était aussi côté OS, en gros l’OS s’arrange pour poller tous les périphériques (via leurs drivers donc) en même temps (ou juste à la suite), comme ça il peut un peu “dormir” entre, et ça joue sur la consommation.
Pour Adobe, là c’est juste une question de compilateur de qualité, surtout que le public qui l’utilise a rarement des vieux ordis, donc on est dans le même style de CPU à peu de choses près (c’est pas la révolution entre une génération Intel 5 et une génération 11). Pour le coup, peu importe les périphériques et les drivers, on est dans du CPU pur.
J’aime chipoter (vu mes commentaires :-) ) mais je suis d’accord avec ça, ça ne peut qu’aider.
#28
Beaucoup plus qu’on le croit de part l’utilisation de certaines libs (crypto, libc…). Par exemple, memset peut utiliser AVX si nécessaire, puis les lecteurs vidéos (pour certains codecs). Ici on couvre tout le monde. Puis rajoute les jeux vidéos et tu retrouves encore de l’AVX. Le reste c’est du soft spécialisés (calculs, audio vidéos…).
Pour l’AVX-512, c’est réglé avec les nouvelles versions de l’architecture (post Skylake-X de mémoire). La diminution de fréquence peut opérer par deux processus (que j’ai constaté par expérience). Soit c’est lié à la température du CPU, soit le processeur considère qu’il peut réduire sa fréquence (mais pas forcément celle des unités AVX) afin d’optimiser sa consommation/chaleur et donc maintenir ses perfs. Évidemment, j’omets les aspects de “ramp-up”.
#29
La crypto a tendance à utiliser des instructions spécialisées hors SSE/AVX, typiquement AES vu le standard que c’est.
Certes mais là c’est vraiment pour un gain de perf pratique qui doit être assez peu notable, sauf à avoir un micro-benchmark. Quand tu vois les perfs d’un memset avec déjà du SSE…
Tiens je viens de regarder dans les logs du noyau et dans dmesg, je ne vois plus trace des tests au boot des différentes méthodes pour memset/memclear. Serait-ce parce qu’à présent ça part sur du SSE d’office ? Note que j’ai regardé ça sur un CPU récent avec AVX2.
Ah tiens j’ai trouvé un test du genre dans dmesg, mais ça concerne les fonctions “gen()” et “xor()” du raid6. Après, même avec du SSE de base, les vitesses sont très importantes (au min 15 et 7 Go/s sur mon i7-8700).
La tendance est quand même fortement à une aide matérielle dans le CPU, hors SSE/AVX. D’ailleurs un CPU pas trop vieux décode pas mal de formats même sans accélération matérielle.
Il me semble que pour un jeu vidéo, les gros calculs sont faits par les cartes graphiques (et beaucoup plus vite d’au moins 1 ordre de grandeur voire 2).
ça ne fonctionne pas ton histoire. Quand un CPU fait de l’AVX2 de façon un peu intense, il chauffe à cause de ces unités (encore plus en AVX-512 vu la taille des données à manipuler), et le CPU est obligé de baisser la fréquence pour tenir dans l’enveloppe thermique (fréquence de l’unité AVX évidemment). Je parle surtout d’un usage multi-coeur, en mono-coeur forcément c’est moins marqué. Si tu fais quelques recherches en ligne ça apparaît clairement.
#30
Le noyau a supprimé le support du 386. Et je ne retrouve plus la source mais GCC ou le noyau tournent par défaut en SSE2 (c’est le minimum en 64bits) sans fallback.
Donc le code est nettoyé d’une grande partie des tests CPUID[“SSE2”] pour ne conserver que les versions SSE2. Dans de rares cas, on peut trouver des contrôles sur des instructions set plus récent, mais il faut soit que ça ait été compilé à la main avec les bonnes options de compilation, soit que le soft contienne lui-même l’optim assembleur.
Edit : ça doit être GCC : https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mfpmath-1
Donc quand les distribs sont passés en 64bits par défaut, elles ont activées le support auto du SSE / SSE2 qui était optionnel avant et donc jamais activé.
#31
La crypto ce n’est pas que de l’AES. Les fonctions de hash (Blake2) ou de dérivation de clés (Argon) utilisent de l’AVX. (e.g., LibSodium).
Certes mais si on croit ce benchmark rapide sur SO, AVX environ ~63% relativement plus rapide que SSE sur un i7-2820QM (mobile) [Donc du SandBridge si je ne me trompe pas]. Il est possible que les Skylakes voir les autres archis fassent un peu mieux.
De mémoire, une archi en 64 bits obligent la présence d’unité SSE. Je vois pas pourquoi le noyau se priverait de ne pas les utiliser au besoin. (Sauf context switch gourmand).
Oui la tendance est fortement au hardware. Mais tu trouves encore du code asm qui utilise ces fonctions comme sur un codec récent (par exemple AV1). Le temps que l’accélération hardware soit implanté dans les cpus.
Mais tout les algorithmes ne s’implémentent pas pour un GPU. Pour celà, le CPU avec ses instructions vectorielles peut changer la donne. (e.g., l’algo de Dijkstra pour le chemin le plus court sur un graph).
Je pensais que tu parlais en mono-coeur.
#32
Oui merci, c’est ça. Les CPU Intel 64 bits ont tous du SSE2 au minimum.
En allant regarder Wikipedia, j’avais oublié que ça datait d’aussi longtemps ; le SSE2 proprement dit sur le Pentium 4 en 2000, le x86-64 en 2003 sur l’Opteron d’AMD, et en 2004 chez Intel (côté Xeon) et plus largement en 2006 avec les Core 2 Merom.