Intel va proposer des Xeon à 48 cœurs, Réactions à la publication du 06/11/2018

[Lionel]

En plus de ses problèmes à graver sous les 14nm, Intel fait face à une concurrence devenue conséquente d'AMD qui propose des puces dotées de très nombreux coeurs.
Pour lutter contre ce concurrent, Intel a annoncé la sortie prochaine de Xeon dotés de 48 coeurs.
Dans la pratique, chaque processeur sera en fait doté de deux puces de 24 coeurs interconnectées au sein du même package.
Il sera de plus possible d'utiliser ces processeurs sur des cartes mères dotées de deux sockets, pour avoir des machines qui auront au total 96 coeurs.

Intel est resté chiche au niveau des spécifications de ces puces, que ce soit le TDP ou encore le nombre de lignes PCI-Express ainsi surtout que leur tarif.

[MàJ] Intel en a dit un peu plus sur ses puces. Elles seraient selon des tests effectués par la société entre 1,5 et 3,4 fois plus véloces qu'un processeur AMD EPYC 7601. Ce processeur a 32 coeurs (64 fils) à 2,2 GHz (turbo entre 2,7 et 3,2 GHz).

Lien vers le billet original

[Sethy]

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

[iAPX]

Tiens, ça me rappelle furieusement les discussions CISC/RISC d'il y a 25 ans !

Aucun rapport, déjà que je ne vois pas ce qu'on pourrait qualifier de RISC ou de CISC aujourd'hui, toutes les CPU modernes (hors IoT et encore) ont des unités SIMD intégrées.

Mais encore faut-il utiliser le SIMD à bon escient, ce que les compilateurs C/C++ ne savent vraiment pas faire hors parallélisme évident (je n'ose parler des autres langages presque tous basés sur du C ou C++!)
Par exemple pour charger une structure alignée de 512bits ou proche, aucun n'a l'idée de déclencher une lecture dans un registre AVX2 pour après balancer les données dans les registres généraux, résultats plein de cycles perdus avec des lectures partielles depuis la ligne dans le cache L1.
Et on perd au passage le bénéfice atomicité de l'architecture Intel lors de l'écriture, obligeant à mettre des clôtures autour (fence) et/ou d'utiliser un sémaphore, ça rend le truc 10X plus lent à la fin!

Les smartphone qui sont -pour moi- des merveilles de technologies intégrant au gros minimum 3 CPU (centrale, communication, stockage), mais souvent bien plus, et des unités spécialisées en veux-tu en voilà (SIMD évidemment, traitement d'image pour la photo/vidéo, Enclave de sécurité, traitement du son, NPU pour le ML, traitement d'empreinte, etc.).

Rien à voir avec un PC ou un Mac de base, et bien plus proche des serveurs spécialisés qui s'appuient sur des unités très efficaces dans un domaine précis et sont architecturés pour des résultats optimaux.
Et c'est là que la CPU n'est pas l'essentiel du serveur mais si elle en est le chef d'orchestre, et que rarement ses performances pures conditionnent celles du serveur, mais l'équilibre de l'ensemble pour les tâches à effectuer au meilleur rapport performance (latence et/ou débit) pour le coût.
Et Intel a un catalogue très fourni pour avoir la bonne CPU à offrir dans chaque contexte, c'est une force.

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

Ce message a été modifié par iAPX - 6 Nov 2018, 22:16.

[otto87]

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

C'est sans doute que tu n'a pas pratiqué l'assembleur su x86, c'est une véritable plaie Et oui les compilos sont des tanches j'ai fais une formation HPC y a 2 semaine, c'est affolant ce que même le compilos d'intel n'est pas capable de trouver tout seul, en mettant à la main les bonnes directives sur des valeur a garder dans les registres, on peut faire du X10 sur des trucs qui se rapprochent de stupides produits de convolution...
Mais bon c'est pareil sur GPU, j'arrive a du X 50 avec du code tweaké à la main alors que pourtant la compilation repose sur LLVM qui est censé être au top!

Sethy : il est plus question de philosophie de code


Ce message a été modifié par otto87 - 6 Nov 2018, 22:42.

[Ze Clubbeur]

PS: quand au M6800 j'en ai bavé avec, et passer son temps à recopier/restaurer X pour faire une simple copie mémoire ça va bien un moment, mais c'était une catastrophe

C'est sans doute que tu n'a pas pratiqué l'assembleur su x86, c'est une véritable plaie Et oui les compilos sont des tanches j'ai fais une formation HPC y a 2 semaine, c'est affolant ce que même le compilos d'intel n'est pas capable de trouver tout seul, en mettant à la main les bonnes directives sur des valeur a garder dans les registres, on peut faire du X10 sur des trucs qui se rapprochent de stupides produits de convolution...
Mais bon c'est pareil sur GPU, j'arrive a du X 50 avec du code tweaké à la main alors que pourtant la compilation repose sur LLVM qui est censé être au top!

Sethy : il est plus question de philosophie de code

Ça me rappelle mes cours de programmation d'il y a jadis... En assembleur, on nous avait fait faire un exercice comparatif... Un truc simple en assembleur et le même programme compilé à partir de C...
Comment dire...

Donc oui, un compilateur est, comme son nom l'indique : con. Il fait bêtement ce qu'on lui demande, sans aucun sens critique et d'optimisation...