Intel a indiqué lors du forum SC15 dédié au HPC que des prototypes de ses Xeon Phi de génération Knights Landing fonctionnaient actuellement dans plusieurs ...
Lire la suite ...

Quel est l'intérêt de graver ce monstre en 72nm ? ( Ou l'inutilité du 14nm )

Pour limiter le rebut je suppose.

La fréquence d'horloge est toujours aux environs de 1GHz ?

 
c'est une coquille je pense... a priori il est gravé en 14nm...

C'est peut être plutôt une coquille car il me semble bien qu'il soit gravé en 14nm
https://software.intel.com/en-us/ar [...] ts-landing

C'est marrant, Intel a choisi une architecture équivalente a celle des FX, des cœurs plus petits qui fonctionnent part paire et se partageant la mémoire cache.    
 
A ce jeu les GPU sont pas plus intéressant ??  

Oui c'est 14nm désolé

Environ 1.3 GHz parait-il.

Ca dépend de l'application : les GPUs peuvent faire plus de calculs (FLOPS) en calcul répétés sur plusieurs cores; mais ils sont bien moins efficaces sur du code avec logique/branchement, accès mémoire non linéaire, travaux plus variés entre les différentes cores etc.
Les CPUs gardent un net avantage en programmation générique.

KL n'est pas non plus trop fait pour du code avec logique/branchement, son intérêt se situe surtout dans les unités AVX-512 qui ont grosso modo les mêmes limitations qu'un GPU il me semble.

 
On pourrait appeler cela un GPU amélioré ? (a peu prêt )

Le gros intérêt surtout, dans le domaine du HPC ou la plupart des utilisateurs ne sont pas informaticiens (mais physiciens, chercheurs, etc), est la compatibilité avec les codes classiques moyennant quelques adaptations.
Du C et par exemple de l'OpenMP ou du MPI tournant sur CPU classiques tournera ici. Cuda fait peur car beaucoup ont testé avec les versions 1 ou 2 où la gestion de la mémoire était délicate, et n'y ont pas retouché depuis.
Maintenant c'est la théorie, en pratique, tirer beaucoup de perfs de ces bestiaux est beaucoup plus dur qu'il n'y parait, en tout cas sur KC (MIC). On verra le KNL.

En théorie c'est du out of order silvermont, donc ça doit pas être fabuleux, mais correct.

Oui mais pour les perfs vectorielles ce ne sont pas les coeurs Silvermont qui entrent en jeu

Depuis les Core 2 (et même encore avant) le cache L2 est partagé entre deux coeurs. Mais sinon pour comparer ça à un GPU, c'est vrai que c'est un peu bâtard comme bestiole. L'idée initiale était bien d'en faire un GPU x86, ça n'a pas abouti mais ça n'était pas à jeter à la poubelle non plus, il semble qu'il y ait des cas d'utilisation.
 
Après, un GPU pur souche n'est pas très optimisé pour avoir une faible latence, c'est pas un problème si on peut alterner entre plein de threads pour éviter les attentes, mais du coup il faut plein de thread par core pour que ça fonctionne bien. L'avantage est qu'on n'a pas besoin d'une logique de contrôle évoluée ou de mémoire cache volumineuse. Pour un CPU c'est le compromis inverse, on met en place des techniques ultra-coûteuses pour être capable de traiter un thread le plus rapidement possible (on peut rarement compter sur un grand nombre de threads).
 
Un Xeon Phi a un peu le cul entre deux chaises, il a certes beaucoup de coeurs et de grosses unités vectorielles (donc il faut pouvoir traiter un grand nombre d'éléments en parallèle), mais ça a des gènes de CPU donc latence faible, d'où le besoin de moins de threads pour être efficace par rapport à un GPU.

On peut installer un Windows sur une machine équipé de ce processeur ? Ou il faut un OS compilé spécialement pour ?
 
Est ce qu'on peut imaginer que ce genre de processeur puisse être utilisé pour des solutions de cloud ou c'est limité au HPC ?

Je n'ai pas regardé précisément pour KNL mais sur les générations précédentes, ces puces fonctionnaient comme des coprocesseurs qui nécessitaient un CPU système.  
 
En pratique les cartes font tourner leur propre mini kernel linux qui fait tourner de son côté une sorte de système séparé et virtualisé. Les applications étaient même découpées en 2 .EXE, un qui allait sur le CPU et un autre envoyé vers le kernel, les deux pouvant communiquer pour envoyer les données etc.

Justement dans la news on parle d'un processeur à part entière sur un socket

Oui j'aurai du relire... Apparemment la mémoire interne (16 Go) sera gérée comme un cache de dernier niveau sur la version socket, et les coeurs exposés directement. Théoriquement avec des coeurs Silvermont ça devrait pouvoir booter un système x86 classique. Pour tirer plein profit, il faudra des apps compilés pour AVX512 par contre, évidemment.  
 
Extrait des disclosures Intel :  
 

 
Pour NUMA (on en avait parlé la en bas : http://www.hardware.fr/articles/86 [...] -numa.html ), le sub clustering risque de limiter a certaines versions de Windows Server par contre (qui a des limites de licences par socket selon les versions).
 
La gestion mémoire devrait être intéréssante en tout cas.

 
 
c'est impressionnant quand même !! combien de transistors ?? on est loin du 2N 3055 bipolaire  
 
si tout cela fonctionne de concert , c'est vraiment une très grande maitrise de la gravure .

MICROARCHITECTURE
Transitors: over 8 billion transistors per die based on Intel’s 14 nm process technology
Cores: up to 72 cores (36 tiles),Core: “Based on Intel® Atom™ core (based on Silvermont microarchitecture) with many HPC enhancements”  
4 Threads / Core
 
Faut compter comment du coups?
36*2*4
72*4
288 Threads ^^
 
Il font faire mal à IBM est ces Power8 et leur pauvre 96 threads (The cores are designed to handle clock rates between 2.5 and 5 GHz.)

Tiens, la scalabilité est la marque de fabrique chère à Sun et IBM avec les Sparc et les Power.
Intel veut vraiment manger à tous les râtelier après avoir timidement loupé son Itanium avec HP.
 

Intel se fatigue peu sur ce coup. Il a repris ses pentium des années 90, les a mise à jour avec les nouvelles fonctionnalités des CPU modernes, et les a mis en parallèle et gravé en 14nm.
Cette architecture est moins performante que l'architecture CPU + GPU sous OpenCL par exemple (sous Cuda certainement aussi mais sur les gros GPU Nvidia des précédentes générations non orientés seulement jeu).
Au demeurant l'AMD Fidji possède près de 9 milliards de transistors sur gravure 28nm.
Il est fort probable qu'AMD sorte un quadruple Hawaii sous 14nm. Hawaii offre une architecture performante complète en englobant en hardware les flottants double précision. D'ailleurs les fonctions AVX ne font qu'essayer de rattraper un peu sur CPU ce que permettent déjà les GPU.
Nul doute qu'un GPU de ce type ne laissera aucune chance, niveau performance, à ces Xeon.

Si c'est basé sur du Silvermont alors c'est quand même un pipeline Out-Of-Order (http://www.realworldtech.com/silvermont/). Mais, ok, le P6 était déjà out-of-order aussi à la fin des années 90

On va pouvoir faire du BOINC pour tourner 72 appli en x86 là dessus ?

@sligor: +1, c'est quand même pas rien comme ajout. Intel ne s'est peut-être pas trop fatigué pour le premier "Xeon Phi" (Larrabee) mais les Atom qui en ont découlé ont beaucoup évolué depuis.
 
Pour répondre à cocto81, pour des tâches complexes où il y a pas mal de divergence entre les éléments à traiter, les GPU commencent à avoir du mal (en lancer de rayons typiquement, les rayons secondaires sur GPU c'est un vrai problème). Un truc un peu moins bourrin qui peut rester efficace avec une granularité d'éléments à traiter plus fine peut tirer son épingle du jeu. Ça reste à voir...

Il y a donc en tout 144 unites vectorielles AVX512.

Ca m'a l'air d'etre parfait pour faire du gros traitement d'images/videos.
Est ce que ce sera plus performant que les GPU actuels ?

Edit: sans compter les 16 Go de RAM (cache ?) à 400Go/s ...

 
Faire tourner, sans problème !
Et c'est pas 72 mais 288 unités en // puisque chaque core dispose de 4 threads
 
Les Xeon Phy précédent le peuvent déjà mais limités par la quantité de RAM embarquée (et avec des applis dédiées).

Me semblait qu'il y avait un problème par rapport aux applis écrites pour du x86 "normal" et qu'on pouvait en fait utiliser ces Xeon Phi uniquement en OpenCL, donc comme des GPU.    
 
Ça avait été rapidement évoqué en 2012 sur un forum dédié à BOINC => http://forum.boinc-af.org/index.ph [...] #msg317192
 
Apparemment des types ont testé sur SETI, mais ça semble peu probant => http://setiathome.berkeley.edu/for [...] id=1439671
 
Je n'en sais pas plus, et saisir un Xeon Phi pour tester revient à un peu cher, m'voyez ?
 
Après, concernant la RAM intégré et limitée, y a des applis qui ne pompent pas des masses, en tout cas moins de 50 Mo. Mais ça posera quand même soucis sur des entrées de gamme des premières générations (3120) avec 6 GB pour 57 cores, donc si j'ai bien compris 228 threads, soit à peine 26 Mo/thread (les 31S1P ont 8 GB). Donc dans le cadre de cette utilisation, point de salut sous les 16 GB (série 7120).

Visiblement c'est un type de mémoire spécifique qui peut être utilisé soit comme cache soit comme mémoire RAM. Intel l'a baptisé MCDRAM

Le principal problème avec les architectures manycore sont les accès mémoire, c'est là qu'est le défis. Un OS (et pas un simple Linux) même en répartissant les métadonnées des threads doit encore faire des synchro entre des zones éloignées du circuit et sa créé des goulot d'étranglement.
 
Tout l'intérêt de ces circuits c'est l'interconnexion, et on n'en parle pas, qu'elle est l'architecture du NoC ?

C'est pas l'OC de gniogniotte ... Tout ces pentium 75 OC à 1000Mhz

Je me demande ce que donnerait ce genre d'archi dans un environnement big data / in memory.
 
Sur SAP HANA, une config "moyenne" à 4 à 8 Xeon E7-2890v2 (de 15coeurs-30threads chacun), soit 120-240 threads et 2To de RAM.
 
4 Knights landing offriraient déjà 288 coeurs et surtout 64Go de cache
Après je ne sais pas si HANA utilise beaucoup l'AVX, ou si ils se concentre sur des instructions x86.
 
Src : https://global.sap.com/community/eb [...] ances.html