Intel : le Core i9-11900T « Rocket Lake » à la course aux performances sur un seul thread avec le Zen 3

…ne savent, ne veulent, ou ne peuvent !
certains calculs dependent toujours du calcul précédent et ne pourront donc jamais etre effectués en parallèle

Pour Intel mais pas pour les autres… ok… Il existe des applis, correctement faites qui prennent les cores dispos que tu en aies 4, 8 ou 64+ sans poser le moindre soucis. Alors faudrait que t’expliques en quoi ça serait la bérézina pour Intel ?
En fait, cela fonctionne dans l’autre sens. Un i7 10700K 8C est plus performant sous Photoshop qu’un AMD 3090X 64C… En effet, quelle bérézina pour AMD ! ^^ (exemple de prog non opti).

Certainement un trou comme la faille du prédicteur de cache chez AMD, présente depuis 2011 et qui impacte encore les Threadripper, Ryzen 7 et autres Epyc.

Y en a pour tout le monde au final

Rien a voir avec intel ou autre, tout avoir avec les applis et les problemes a traiter
Un pb pouvant utiliser plusieurs coeurs:
j’ai une tres grande image et je veux y chercher qqchose.
on peut découper l’image en 64 portions (si on a 64 coeurs) et laisser chaque coeur y chercher le qqchose.
Un pb ne pouvant pas etre traiter par plusieurs coeurs:
Calculer la trajectoire d’une balle qui rebondit sur un sol irregulier.
La trajectoire est une succession de positions dont chacune dépend de la précédente.
Cela ne peut donc pas etre découpé pour etre traité par plusieurs coeurs.

ps: le « decoupage » a un cout et parfois il peut etre supérieur au gain de la parallélisation

Oui et non.

L’idée du multicoeur ou multithread pour le logiciel est d’exécuter en distribution ce qui est séquentiel, et évidemment de paralléliser ce qui est possible.

Ainsi, en vulgarisant à l’extrême, plutôt que d’avoir :

• Core 1 => Exécute A, puis B qui dépend de A, puis C qui dépend B

on aura :

• Core 1 : Exécute A, Exécute C dès que B fini
• Core 2 : Exécute B dès que A fini

L’idée est que chaque Coeur tourne à sa fréquence optimale pour exécuter sa tâche dans un temps dédié, et que chaque Coeur ne consomme en énergie ce qui est nécessaire en plus de soulager la dissipation thermique.

Alors évidemment, dans la pratique et pour une majorité des logiciels :

• Core 1 va être à 70% car il exécutera le gros des tâches
• Core 2-3-4 seront à 25% pour ce qui est distribuable et parallélisable

Mais au final, c’est mieux que Core 1 à 100% qui s’occupe de tout.

Pour une machine desktop, A part le rendu 3D et le montage vidéo, et en dehors des serveurs, je pense qu un processeur à 64 cœurs n apportera rien de plus qu un 8 cœurs simplement parce que beaucoup de choses ne peuvent pas être autant parallélisees.

Meilleur exemple: les jeux vidéos. Au delà de 8 cœurs, aucun intérêt. Idem pour la suite Adobe CC qui est optimisée pour 8 cœurs.

Par ailleurs, le fait qu Apple parte sur une architecture 8 cœurs pour sa puce M1 risque d inciter les devs à optimiser encore plus leur code pour ce nombre de cœurs. Quel intérêt de tout réécrire pour un nombre de processeurs qui ne représente que quelques % du marché ? (Ceux qui ont plus que 8 cœurs physiques)

Mauvais exemple, au contraire ici core 2 ne sert a rien, pire le changement de contexte pourrait ralentir l’execution globale.
Des taches sequentiels sont séquentielles, point.
des taches parallélisables peuvent elles etre distribuées entre coeurs.
Cela dépend complement des pbs a traiter.

La suite Adobe CC est optimisée pour 8 cœurs, c est indiqué sur la fiche matérielle. Donc au delà, aucun intérêt.

Par contre, des logiciels comme Cinema4D ou 3DS Max utilisent tous les cœurs disponibles pour le rendu 3D. La aussi c est écrit et d ailleurs, ça se voit clairement lorsque les rendus sont executes.

Oui la 3D est un bon exemple, les algos de raytracing sont hautement distribuables
en caricaturant, on pourrait avoir autant de coeurs que de pixels a calculer.

Comme je le disais c’est vulgarisé à l’extrême. Mais cela reste pourtant un exemple simple à comprendre.

Tout « code séquentiel » peut être découpé en instance de codes, c’est à dire au final des tâches. Et chaque tâche peut alors être mis en « concurrence » (gérer plusieurs choses à la fois) ou en « parallélisation » (gérer plusieurs choses en 1 fois). Au final, tout dépend de l’optimisation réalisée au niveau logiciel et micro-logiciel, car évidemment, une mauvaise concurrence entraînera plus de ralentissement qu’autre chose.

C’est le même principe pour la charge de serveur et dans bien d’autres domaines (architecture de stade avec les principes de mécanique des fluides, etc.). 1 seule voie n’est pas toujours la meilleure solution (en termes d’optimisation et évolutivité).

Mais bref. On dérive du sujet initial (article).

90% du temps, les logiciels n’ont qu’une tâche à exécuter à la fois. Voire deux.
Il est souvent intéressant aussi de se focaliser sur un seul coeur pour maximiser le cache hit.

Ici, on parle des séries « T » de chez Intel qui sont les séries basse conso: on les utilise rarement pour le calcul intensif ou hautement parallélisé.

Après, je préfère voir les performances sur un gros fichier excel, c’est souvent plus parlant…

Enfin, le retour d’AMD est impressionant, mais AMD n’a jamais mis une raclée à intel du niveau de celle que intel mettait à AMD pendant des années: les processeurs des 2 marques sont très bons voire excellents.
De même pour la « claque » de l’Apple M1, elle n’est pas générale.

Intel a parfaitement raison de mettre en avant ce résultat: je trouve qu’il a du sens.

Pour le trou de sécurité, il va falloir attendre pour savoir - mais il faut aussi noter que pour exploiter les « trous » de sécurité, il faut faire tourner des processus pendant des heures à quasi à 100% du CPU, ce qui ne passe pas inaperçu…