Reprise du message précédent :
Tu penses mal
 
http://newsroom.intel.com/communit [...] -analytics
 

ICI

Ok... Si je comprends bien, le but est d'utiliser un ou plusieurs cores pour exécuter l'application, qui va distribuer le programme et/ou les données aux autres cores. Si c'est cela, je tombe sur le cul ! Ce système a été expérimenté il y a 20 ans avec les transputers, pour un résultat très décevant. Plus récemment, il y a eu d'autres expérimentation, du coté d'IBM entre autre, tout aussi décevant. Je ne vois vraiment pas ce que vient faire Intel en relançant cette idée. Le core basique du Xeon phi est faible en calcul, coûteux (je pense que la MCRAM n'est pas donnée) et cela pose de gros problème pour la communication avec l'extérieur. Le but d'une puce dédiée au calcul est de faire une chose très spécifique (par ex du calcul en parallèle sur de multiples données), et pas d'exécuter un programme séquentiellement. Je trouve le procédé d'Intel très vicieux, d'aller adapter une architecture x86 (donc non spécialisée) au calcul SIMD en multipliant les cores et les instructions, pour après demander a ces cores de faire du séquentiel...  
Et puis mince alors, a quoi vont servir leurs 36 lignes PCI-Ex 3.0 ? Ce sont les Atoms "maitres" qui vont pouvoir gérer le flux des données ? Sans rire...

 
A mon avis, la communication intra CPU permet largement de compenser la difference de perf d'un Xeon Phi face a un couple Xeon+GPU.
De meme, la difference de TDP est compensé par le fait que dans un cas, tu auras un CPU certes plus gourmand, mais rien d'autre a coté alors que dans l'autre, un GPU peut etre un peu moins energivore, mais qui necessite un CPU en plus avec son TDP a lui aussi.
Et je fais largement confiance a intel et sa maitrise des process de (finesse de ) gravure meme si la derniere news sur le 14nm aurait tendance a me faire mentir, pr avoir des systemes pas si energivores que ça au global, et pour tjrs avoir un train d'avance sur AMD et Nivida (enfin plutot les fondeurs, TSMC en prime, globalfoundries UMC derriere) sur ce point.
Et enfin, Intel a la maitrise de toute la plateforme puisque ce sont leur chipsets qu'on retrouve apres sur les CMs, quand AMD et Nvidia n'ont rien d'autres (c'est moins vrai pr AMD, mais bon) que des cartes additionnelles.

Argument rejeté, c'est pas un SoC ARM avec ses 8 watts qui pourra handicaper le TDP final d'un système ARM + GPU NVidia. Et même dans les systèmes actuels, on peut trouver des CPU "low power" qui tournent dans les 35 Watts.

J'ai du louper un truc là. Tes calculs massivement parallèles sont exécutés par les unités AVX-512, qui sont pilotés par les Atom Silvermont. Quant à la MCDRAM, quel rapport ? Elle n'est pas tant là pour les coeurs Silvermont que pour assurer l'alimentation des unités AVX-512 dans le cadre de calculs massivement //, pourquoi la remettre sur la table à ce niveau ?
 
Le passage en Socket n'est que la suite logique du fonctionnement actuel des Xeon Phi, qui font pour rappel tourner leur propre système d'exploitation au sein duquel on fait tourner les programmes. Quel est l'intérêt d'associer Xeon Phi et Xeon si au final le Xeon ne fait rien si ce n'est lancer un OS primaire qui permet d'accéder à l'OS du Xeon Phi ? Bien sûr si ce n'est pas pour traiter des calculs massivement //, un Xeon Phi est un veau puisque ce sont uniquement les Silvermont qui pourront s'en charger, et dans ce cas il vaut mieux tourner directement sur le Xeon et un système Xeon + Xeon Phi (qui sera tjs possible) est de fait plus polyvalent. Mais pour un système accueillant exclusivement du calcul massivement // je ne vois pas le problème à avoir du Xeon Phi uniquement.

La MCDRAM est a priori là pour accélérer l'accès entre les cores. Tu vas donc l'utiliser pour exécuter ton code et accéder a tes données. Si le système tourne complètement sur les cores Phi, ça va manger de la bande passante qui aurait du être disponible pour le calcul. Exemple au début de ton calcul tu vas envoyer ton code + data aux autres cores. Puis ils vont l'exécuter et chercher a envoyer le résultat aux cores dédiés a la gestion, qui vont eux-même les retransmettre vers l'extérieur. Ça va créer de la contention sur les bus de données, sans être pour autant plus rapide car certains cores ne seront pas utilisés a leur plein potentiel (en fait les unités AVX). Avec un CPU externe, tu as moins de problèmes, ou alors ils ont un "truc".
 
En fait, j'ai l'impression que Intel veut s'orienter vers un réseau de processeurs spécialisés, plus que du calcul // pur.

Il ne faut pas tout ramener a Cuda, ce n'est pas comme ca que fonctionnent les Xeon Phi. Il n'y a pas d'opposition entre les cores Silvermont et les unités 512 bits (VP sur le schéma, voir l'endroit ou c'est marqué Tile). Les unités VP sont intégrées sur (ici) 2 ports du processeur et il n'y a pas la même notion de contrôle nécéssaire.  
 
Je prends l'exemple de KNL ici, mais c'est globalement pareil pour KNC (l'actuel Xeon Phi).  
 
Intel dit utiliser des cores Silvermont. Chaque core est cependant très différent des Silvermont que l'on connait, en premier lieu parce qu'il gère 4 threads en // (Silvermont ne gère pas l'HT de base, contrairement au P54C de KNC). Silvermont est en plus OOO. On a donc bien un pipeline OOO capable de réordonnancer les instructions classiques, mais qui ne touchera pas à l'ordre des instructions FP.  
 
Quand on compile contre un Xeon Phi, le code produit va mélanger à la fois du x86 basique (pour le flow control et autre) et des instructions FP. Sur l'actuel Xeon Phi ca se traduit par compiler du x86+l'extension LRBni, et avec KNL LRBni est remplacé par AVX3, que l'on retrouvera aussi exploité sur Skylake sous une autre forme (moins rapide mais compatible sur le jeu d'instruction).

Oky, je comprends un peu mieux. C'est vrai que les Xeon Phi ce n'est pas mon domaine, c'est effectivement très différent de CUDA.
 
Hors sujet : quand a Silvermont, j'ai cru voir une annonce sur des modèles J1800, J1900 et J2900 avec multicore et Turbo boost. Confirmé ?

Ces références sont des Bay-Trail-D, oui :
 
  http://ark.intel.com/compare/78867,78866,76531,76530  

ça donnerait quoi comme rapport de perfs à mon i7-920 ?

Pas trop de comparaison pour l'instant, les seuls chiffres que j'ai sont un indice CPU Mark de 1814 pour le J1850 @2.0 Ghz et 10 W, comparé à un Celeron G530T @2.0 Ghz (1604 / 35 W) ou un C2D E8200 @2.66 Ghz (1845 / 65 W).
Le i7-920 n'est pas un CPU dans la gamme "basse consommation" (130 W).

AMHA il parlait des Xeon Phi, mais c'est pas vraiment possible de comparer ce genre de chose.

si tu lances un test de calcul massivement parallele, là le Xeon-Phi il va exploser le i7-920 quelque chose de mignon.
Comme le dit Marc, c'est pas prévu pour faire le meme boulot.

Je pensais pas qu'on pouvait demander a comparer des patates et des carottes