Un PC de démo, une machine de bureau standard, a montré les capacités de la prochaine génération Raptor Lake d’Intel en action. Cette treizième génération de puce Core d’Intel montre des capacités intéressantes et dévoile ce que l’on peut attendre des choix technologiques qui sont fait par le fondeur.
La 13e génération de processeurs Intel, Raptor Lake, accumulera jusqu’à 8 coeurs hautes performances et 16 coeurs moins rapide mais très peu gourmands ensemble. Un total qui permettra de piloter jusqu’à 32 threads en simultané. Une gamme qui devrait permettre une augmentation de performances sensible par rapport à la génération Alder Lake même si aucun chiffre précis n’a été donné pour le moment. On restera sur une architecture « Hybride » chez Intel.
Prévus pour cette année, ces puces Raptor Lake seront compatibles avec les sockets des carte mères embarquant les actuels Alder Lake pour les machines de bureaux mais aussi avec les circuits BGA des solutions mobiles. De telle sorte qu’un fabricant pourra exploiter une même carte mère de portable et faire évoluer sa puce d’un Alder Lake à un Raptor Lake pour rafraichir sa gamme. Un mouvement intéressant car il permet en général d’amortir plus facilement le tarif des engins avec les nouvelles puces. Un mouvement qui casse également la mauvaise habitude prise par un Intel sans concurrent quand il s’agissait de proposer de nouvelles puces. La marque ayant tendance a forcer au rachat de nouvelles carte mère trop systématiquement ces dernières années face à un AMD qui savait exploiter les mêmes sockets et chipsets.
Un des point les plus intéressant de cette nouvelle approche amorcée avec Alder Lake et développée avec Raptor Lake, c’est dans l’usage des coeurs et de leurs capacités. Dans la démonstration ci-dessus, Intel montre comment sa puce peut occuper la totalité de son processeur à 100% de ses capacités pour un travail de rendu sous Blender. Une tâche extrêmement lourde qui va demander le maximum de ressources pour être terminée le plus vite possible. Et on voit au lancement de la tâche que l’ensemble des threads du processeurs sont occupés à 100% de leur capacités pour travailler le plus vite possible.
La totalité des ressources est dédiée au calcul de rendu
Rien de nouveau là dedans, c’est comme cela que fonctionnent les puces classiques. Ce qui va changer c’est l’opportunité laissée par Raptor Lake de continuer a utiliser la machine pour d’autres tâches de manière fluide. En basculant la fenêtre du logiciel Blender en tâche de fond, le processeur réagit immédiatement. Les 16 Threads du bas du tableau, ceux qui correspondent aux cœurs « efficient », restent alors occupés à 100% de leur capacités pour calculer ce rendu. Les 16 coeurs « performance » se libèrent quand a eux pour gérer de nouvelles tâches.
Des ressources se libèrent pour d’autres calculs
Le résultat est assez évident, on retrouve une machine exploitable pour de nouvelles tâches pendant que le rendu de l’image 3D, ou tout autre tâche, est effectué en « douceur » en arrière plan. La philosophie d’Intel est assez simple ici. C’est l’utilisateur qui choisi suivant ses besoins et son planning. Si il veut absolument que sa machine aille le plus vite possible pour calculer son image, il laissera le programme au premier plan et ne toucheras plus à rien. Si la vitesse de ce rendu n’est pas aussi primordiale ou si il faut qu’il fasse absolument autre chose de sa machine pendant ce rendu, il pourra le faire.
En bas le calcul du rendu est toujours en cours, en haut une tâche a sollicité brièvement les coeurs
L’exemple pris ici est extrême puisqu’il s’agit de gommer un élément dans un fragment de vidéo, ce qui implique la recherche et la détection de cet élément dans des centaines d’images et le remplacement de celle-ci par un fond qui soit raccord avec le reste de l’image. Ce nouveau calcul est donc effectué sur les 16 threads performance de la machine pendant que les 16 autres threads continuent de travailler au rendu de l’image sous Blender. Ce que propose ici Intel avec Raptor Lake c’est de livrer un engin qui permettra d’effectuer des tâches lourdes et longues sans bloquer le PC pour autant pour d’autres tâches complexes. et cela sans avoir a faire d’autres manipulation plus complexes qu’un simple basculement de tâche en arrière plan.
Autre élément intéressant proposé par la plateforme, l’arrivée d’une solution destinée à l’accélération des calculs d’IA sous la forme d’une carte au format M.2. Une solution Intel qui devrait trouvé du couple en fonctionnant avec la nouvelle gamme de puces. Pas forcément l’ajout dont tout le monde à besoin mais qui pourrait être très utiles dans certains usages. Le recours au format M.2 permettant d’employer cette solution sur une majorité de machines.
Intel a également profité de cette session pour parler de ses futures puces Meteor Lake et Arrow Lake. Le premier suivra Raptor Lake en 2023 dans un rythme assez effréné donc par rapport aux dernières années d’Intel qui semblait faire beaucoup de « sur place ».
Ce processeur devrait utiliser une autre structure technique que la technologie Hybride. Intel l’a baptisée « disaggregated » pour « désagrégée »… Une appellation qui s’explique par une interconnexion entre le circuit graphique et les coeurs via la technologie EMIB d’Intel. La partie coeurs de calcul emploiera la technologie Intel 4 soit du 7 nanomètres. Le circuit graphique étant quand à lui le premier « tGPU » du fondeur. Une nouvelle solution qui emploiera la prochaine génération de l’architecture Intel Xe. Cette puce embarquera un circuit d’accélération d’IA en interne. Ce nouveau schéma d’implantation devrait permettre à Intel de construire des processeurs aux capacités très différentes. La marque n’aura qu’à piocher dans sa gamme de coeurs et de circuits graphiques pour construire ses puces comme des puzzles de composants.
Arrow Lake est prévu pour 2024 avec la même philosophie d’usage mais une évolution probable des architectures et l’emploi du process de gravure 20A d’Intel. On a moins d’information sur cette puce sinon qu’elle reprendra le socket de Meteor Lake, socket qui sera différent de celui des Alder Lake et Raptor Lake.
Lunar Lake enfin, dernière puce évoquée par Intel, serait une recherche effectuée par le fondeur autour de sa technologie de gravure 18A. Prévu pour 2024 c’est probablement la poussée en avant de puces moins gourmandes et plus efficaces. Cette nouvelle solution semble débarquer sur un segment différent puisqu’il sortira en même temps que Arrow Lake. On peut espérer des solutions à très basse consommation exploitant toutes les avancées techniques des processeurs de la marque. Tant sur le plan architectural que sur l’implantation et les fonctions annexes au niveau du processeur graphique.
Lunar Lake promet pour le moment d’être très efficace, avec une consommation de watts très faible pour un niveau de performances avancées. Au vu des solutions proposées par la marque pour le futur on peut s’attendre à des puces très étagées qui fonctionneront dans une enveloppe de quelques watts seulement à des processeurs un peu plus gourmands mais qui garderont, on l’espère, toujours la tête froide.
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
> La 13e génération de processeurs Intel, Raptor Lake, accumulera jusqu’à 8 coeurs hautes performances et 16 coeurs moins rapide mais très peu gourmands ensemble. Un total qui permettra de piloter jusqu’à 16 threads en simultané.
Ce ne serait pas 32 threads plutôt ?
Sinon excellent article, hâte de voir ce que ça va donner lorsqu’elles sortiront :)
J’ai laissé tombé Intel depuis 2017. Trop de socket/chipset/carte mère à chaque génération de cpu … trop difficile pour le portefeuille de suivre (sans parler des appellations marketing). Coté AMD avec la stabilité du socket AM4 c’était +simple (4 générations de cpu)
A voir avec les nouvelles fonctionnalités autour de l’IA/deep learning (ce n’est pas des besoins mainstream … mais c’est mon boulot) … si Intel arrive à proposer un écosystème aussi riche fonctionnellement que Nvidia/Cuda, on regardera de près :-)
Avant autant de coeurs, les pirates pourront miner avec nos PC sans qu’on le sache. :)
J’ai du mal à comprendre en quoi réserver x coeurs à telle appli serait plus efficient que ne réserver personne mais que la tâche en avant plan ait une prio plus haute que celle en arrière plan.
On continue ainsi d’exploiter 100% de la capa du CPU, simplement si la tâche d’avant plan nécessite 20% pendant dix secondes, ils lui sont alloués au détriment de la tâche de fond. et 10 secondes plus tard de nouveau 100% est alloué à la tâche de fond ‘pour ne pas gâcher de la capa qui paraît inutilisée sinon dans l’exemple de l’article.
@nouknouk: Tu réfléchis avec les capacités des anciennes puces en fait. Ici on a un processeur capable de faire 2 tâches particulièrement lourdes en parrallèle ce qui ouvre de nouveaux usages. L’exemple du rendu Blender est bien choisi pour cela parce que tu parles de « 10 secondes » mais un rendu d’une animation Blender peut prendre « des heures » voir « des dizaines d’heures ». Et donc la formule d’Intel permet d’allouer une journée de travail complète sur son PC pendant que le rendu s’effectue en « sous-marin » sans avoir a accumuler 2 PC sous son bureau ni trop ralentir le processus. C’est sur que pour 10 secondes cela ne parait pas pertinent mais imagine toi devoir calculer une vidéo d’un côté et effectuer un montage de l’autre, au lieu d’avoir 2 PC tu en as un seul pour les deux tâches avec une optimisation automatique des ressources en fonction de ce que tu mets en premier plan. C’est plutôt pas mal non ?
@Pierre Lecourt: je lis beaucoup vos articles et apprécie énormément votre site et apprécie vos jugements sur le matériel car je les trouve suivent pertinent. Concernant la remarque de nouknouk, en tant que sysadmin de métier, je rejoins complètement son avis. Je suis en télé-travail depuis 10 ans et je travaille toute la journée sur mon PC, de gros serveurs et énormément de machine virtuelles et il m’arrive régulièrement de recompiler des systèmes linux entiers localement sur mon PC, ce qui charge mon CPU à 100% pour des heures voir des jours. Et c’est le travail du scheduler du noyau (quel que soit l’OS) de gérer cela, pas celui de l’utilisateur. Et heureusement, je ne m’arrête pas de travailler lorsque ça compile en utilisant 100% du CPU, et je peux lancer la compilation de plusieurs systèmes en parallèle sans aucun impact sur mon travail. Si on veut affiner les priorités des taches, on peut le faire (commande nice) mais sans modifier quoi que ce soit, un usage bureautique lourd n’est pas du tout affecté à l’usage alors que le PC est chargé à 100%.
A la limite tu peux avoir un ralentissement observable du à un bottleneck réseau ou disque mais pas sur des taches sur un CPU avec un minimum de 4 cores. En effet en dessous de 4 cores, ca peut poser des problème car les IO peuvent bloquer certains cores et donc les taches en avant plan peuvent se battre avec un calcul lourd pour les cores restants.
Quant aux IO, si cela peut rester un problème pour du stockage mécanique, il faudra taper très fort avec des accès aléatoires et en parallèle pour commencer a voir le problème sur un bon SSD (dans ce cas il faut éviter les mauvais SSD qui ont de mauvaises performances, une fois la cache mémoire saturée). Et si le but c’est de ne pas être impacter par une lourde tache avec beaucoup d’I/O qui utiliserait les mêmes ressource système tu peux toujours préciser à ton système des priorités I/O via la commande ionice ou être plus malin tout simplement en séparant tes ressources (un disque pour le système, un autre pour les taches lourdes en IO, une carte réseau pour l’usage courant, une autre pour des taches lourdes en réseau, bref diviser pour régner).
C’est donc le job du scheduler de gérer le CPU et dans certains cas extremes, on peut lui indiquer certaines priorités mais depuis le multi-cores et le SSD, ca devient des cas vraiment spécifiques.
Après je ne connais pas les performances actuelles du scheduler de Redmont mais ça reste à lui de faire le job, pas à l’utilisateur.
Le seul cas d’usage que j’y verrais en pratique, ce serait pour maximiser l’autonomie d’un système sur batterie et donc de privilégier un calcul lourd sur des cores plus efficients au niveau consommation électrique au détriment du temps de traitement. Ce qui reviendrais à lancer le calcul lourd sur moins de cores sur un CPU multicores avec une architecture classique non big-little.
Une architecture Big Little a du sens à mes yeux que pour l’efficacité énergétique d’où son usage sur un téléphone/tablette et possiblement sur un ultra-portable ou le besoin de puissance est sporadique. Car si tu as un réel besoin de puissance, il n’y a aucun gain a ce type d’architecture tant que la consommation en idle d’un gros processeur multi-cores est maitrisé (baisse auto voltage/frequence et cores en idle via les C-States) car en effet tu consommera peu si tu utilises peu et vice et versa.
L’architecture Big Little d’intel a été introduite à mon sens purement pour concurrencer AMD car les cores Intel consomment plus actuellement sous forte charge et il est difficile pour intel actuellement de maitriser le consommation électrique à nombres de threads égal avec AMD. L’architecture Big Little leur permettent d’obtenir un nombre de threads comparables à AMD sans trop exploser la consommation électrique à l’usage mais cette architecture soumise à une longue et forte charge consomme beaucoup.
@Pierre Lecourt: Ce serait pratique de pouvoir éditer un commentaire notamment pour corriger ses propres fautes d’orthographe et/ou de grammaire. Je m’excuse donc au près des autres lecteurs pour celle que j’ai laissé sur mon précédent post.
@zentoo: Je comprend bien cette position mais encore une fois elle correspond à une génération de puces précédentes. Ici le choix fait par Intel est de multiplier les coeurs et leurs performances pour que le système puisse mener à bien 2 tâches lourdes en parrallèle. Ce qui, il me semble, n’empêchera pas de réattribuer à la volée la totalité des performances à la tâche principale (en avant plan) si le besoin s’en fait sentir. Je trouve ça pertinent pour un utilisateur lambda de pouvoir récupérer la main à la volée sur les perfs et de laisser le CPU se débrouiller en sous marin.
Le soucis c’est qu’Intel propose quelque chose à côté de Microsoft et si les deux travaillent probablement de concert, l’harmonie n’est sans doute plus une de leur priorité. Alors ou i c’est à Windows de faire ce job mais espérer qu’il le fera est clairement un voeu pieu et pas une certitude pour Intel. La proposition de faire réagir le CPU en fonction d’éléments simples (fenêtres basculées en arrière plan) est assez pertinent.
Aujourd’hui si je veux faire un rendu vidéo sous Resolve Windows 10 et que je rouvre une page de Photoshop, j’aurais des ralentissements sur… les deux programmes. Ce qui fait que je lance mes rendus sur une machine annexe, sur une base de Xeon + Quadro, qui ne sert quasiment qu’à cela. Est-ce que ce choix d’Intel vient pour concurrencer AMD ? Je ne suis même plus sûr. Je pense qu’il s’agit ici de concurrencer Apple et ses M1 qui peuvent sans soucis piloter un rendu 8K et libérer la machine pour faire autre chose avec une vitesse et une souplesse inégalable et pour quelques watts.
La vraie cible d’Intel sur ce segment créatif ce n’est pas AMD, c’est Apple. Et le futur de ses puces c’est clairement une bataille qui va s’engager contre Apple/ARM/M1.
Cela dit ton commentaire est très pertinent et intéressant. Merci.
PS : L’édit sur les commentaire c’est trop dangereux. J’ai déjà du mal a bien modérer les commentaires pour éviter les spams/pub/messages politiques… Alors si on pouvait éditer les anciens ce serait l’enfer :(
Je rejoins zentoo. On parle d’une assignation de prio du scheduler en fonction du focus du user (et btw, zentoo, on a les prio également pour les io: ionice).
Les graphes de l’article parlent d’eux même: en mode arrière plan on a de la capa CPU qui est juste inutilisée.
L’inverse de la notion d’efficience.
Un auto-set de la prio en fonction du process correspondant à la fenêtre en avant plan peut se vider sous linux, win, en quelques dizaines de lignes empaquetées dans un soft tiers sans aucun besoin ni de spécifique côté os, ni fabriquant du CPU. Et on peut obtenir ce que tu décris: le soft en avant plan totalement réactif même si un autre en arrière plan continue de manger tout ce qui reste de dispo.
Si on devait faire une analogie: le scheduler avec prio sur les process (qui existe depuis 30+ ans) et l’allocation dynamique des ressources dispo en tps réel, c’est le principe des conteneurs comparé à la proposition d’allocation statique des ressources qui correspond au fonctionnement des machines virtuelles.
Bref, soit j’ai TRES mal compris l’article, soit l’article passe total a côté de ce qu’a en réalité présenté Intel, soit Intel a vendu du vent.
@nouknouk: Je crois que je vois ce que vous voulez dire et ce qui ne passe pas. La solution d’Intel c’est d’offrir de la disponibilité permanente de processeur pour tout un tas de tâches quand vous décidez de mettre le processus le plus gourmand en second plan. Est-ce que c’est plus pertinent ou moins pertinent que la solution classique ? Je n’en sais rien je n’ai pas testé. J’ose imaginer qu’Intel y voit un intérêt par rapport à sa solution hybride et comme les ingés de la boite ne sont pas des crétins, j’ose espérer qu’il y a là un vrai usage. L’idée de proposer une machine réellement dispo pour toute autre tâche malgré un emploi massif de calcul en arrière plan. Et cela pour ne pas trop ralentir cette seconde tâche justement. Fabriquer une sorte de cluster de calcul d’un côté pour le front et un second dédié en arrière plan.
Est-ce moins efficient en terme de puissance attribuée ? Peut être. Mais en terme d’usage ? Pour l’utilisateur qui va se retrouver avec PC ahanant pour des tâches simples parce qu’en train de calculer massivement en tâche de fond ? Tout en rognant autant de l’autre côté la vitesse de calcul qui deviendra moins bonne. Parce que c’est comme cela que ça se passe en pratique sous Windows aujourd’hui…
Si ce n’est pas plus pertinent qu’une solution classique, ce sera dommage pour Intel. Mais si cela s’avère plus souple et agréable au quotidien pour un utilisateur lambda, ce sera néanmoins intéressant. Nous verrons bien à l’usage.
@nouknouk, @zentoo et @Pierre: je crains que vous ne vous égariez sur une compréhension erronée du déroulement de l’exécution des tâches (jobs, cgroup) processus (process) et fils (threads) présentée ici et dans la vidéo d’Intel.
Intel propose pour la puce au travers du Thread Director et de l’ACPI aussi, des recommandations de placements plus optimaux sur des critères de performance, ou d’efficience et de capacité(enveloppe thermique) et les programmateurs/organisateurs d’exécution (scheduler) des différents systèmes d’exploitation dans leurs différentes versions ou composants utilisent cette info ou pas pour programmer des fils d’exécution sur certains cœurs en particulier. C’est donc l’OS qui impose les choix.
Dans Windows les choix entre un placement performant et efficient quand ces éléments divergent sont fait selon les préférences d’alimentation de la machine (économe, performances maximales etc..). Windows client est un OS avec interface graphique par défaut par défaut, de fait les applications interactives et au premier plan ont toujours eu un surcroit de priorité sur celle ne l’étant pas. Une information légèrement plus technique et exacte est donnée ici.
Comme @Zentoo l’a mentionné, Linux favorise plus volontiers le débit en terme exécution de fils, et présente le plus souvent et par défaut des priorités indifférenciées entre les tâches interactives (shell) ou en lots, de premier plan ou pas. Des modestes divergences existent cependant entre les distributions et les interfaces graphiques, elles mêmes promulguant leurs propres fils d’exécution ou ceux des taches dont elles ordonnent le lancement.
Enfin les téléphones Android et ARM proposent depuis des années et l’introduction des architectures big.LITTLE des programmateurs de fils qui accomplissent la même chose que la réalisation d’Intel. Il est d’ailleurs étonnant de voir la variance pour des plateformes très proches (même SOC, refroidissement proche) en terme d’autonomie (indirectement d’efficience) ou de performances instantanées, reflétant des réglages et des optimisations différentes choisis par les constructeurs ou les vendeurs.
Cela constitue pour Intel, AMD, ARM, Samsung, Qualcomm, Mediatek et d’autres des points de différentiation jugés essentiels entre leurs produits et ils ne le dévoilent pas comp^létement afin de protéger leur propriété intellectuelle.
Merci pour les précisions webm, c’est plus clair pour moi: Intel va fournir des infos complémentaires au scheduler de l’os au dessus qui pourra -s’il veut- prendre en compte pour optimiser l’allocation des tâches aux différents coeurs.
@calvin: voir la nouveauté d’Intel :
https://www.cnx-software.com/2022/01/05/intel-mobileye-eyeq-ultra-risc-v-processor-targets-level-4-autonomous-driving/
@zentoo:
et @nouknouk: +1
« Bref, soit j’ai TRES mal compris l’article, soit l’article passe total a côté de ce qu’a en réalité présenté Intel, soit Intel a vendu du vent. »
Intel est très bon en logiciel, mais ce n’est pas rare qu’il vende du vent…
AMD a dépassé la capitalisation boursière d’Intel qui vient de se prendre encore un -5%.