Après AMD et Nvidia, c'est ce soir au tour d'Intel d'annoncer officiellement ses cartes accélératrices pour calculs parallèles dédiées au marché HPC (Hautes ...
Lire la suite ...

300W en passif ? Je suppose qu'il faut avoir un ventilateur qui souffle quasiment directement dessus...

C'est des cartes pour serveurs. Les serveurs ont des lignes de ventilo qui soufflent directement sur les cartes d'extension.

 
Non pas tu tout les salles sont réfrigéré par de l'airco http://www.youtube.com/watch?v=s7u-oTV4PdA  

Si tu ouvres un serveur u par exemple, tu y trouveras des ventilos entre la partie disques et la partie carte mère / extensions.
Après pas tout le monde a une super salle climatisée comme dans la vidéo.

Leur "Petit tacle en passant à la concurrence…" est au mieux de mauvaise foi, au pire, idiot. Avec un Phi il faut faire exactement la même chose: Transférer les données depuis le CPU, calculer et récupérer les données. Le bus PCIE n'est pas plus rapide si la flêche est bleue .

Toi, tu n'as pas lu le slide...

 
C'est gentil de me prendre pour un attarde mais je pense avoir au moins lu le slide. Intel, me semble-t-il, melange deux idees: (1) l'unicite du source pour la performance sur toutes les plateformes et (2) offload/merge de donnees (donc transfert vers/depuis le GPU).
 
Pour (1), je doute qu'ils obtiennent 800GFlops/s sur DGEMM ou 85% d'efficacite sur LINPACK avec le meme code que celui pour Xeon. Pour (2), il n'y a pas de difference entre GPU et Phi (qui sous bien des abords est plus proche d'un GPU que d'un CPU).

Non: "offload parrallel section" se réfère au travail de codage pour adapter à CUDA les parties du programme qui seront traitées par le GPU.
 
Il est fort possible par ailleurs que le Xenon phi, fort de ses CPU P54C, de son support du X86, et de son système d'exploitation propre, soit beaucoup plus indépendant qu'un simple GPU.
 
Mais Intel n'en fait pas mention car contrairement à ce que tu penses, le lien PCI-E est loin d'être un facteur limitatif.
 
Par contre la puissance théorique du Xeon repose entièrement sur ses unités vect16.
Et l'on sait déjà qu'en pratique, elles risquent d'être souvent sous utilisées.

Pour le PCI-E en GPU Computing, cela dépend beaucoup des traitements, je ne serais pas si affirmatif que toi regis183

On verra bien
En tout cas Intel ne base pas trop sa communication sur les performances pures.
 
Là ça ressemble plutôt à du:
- soit vous achetez chez nous et l'accélération matérielle sera prise en charge de façon transparente.
- soit vous adaptez votre code aux GPU concurrents, mais vous allez en baver.
- soit vous utilisez des GPU sur compilateur Intel, mais les performances seront minables.

J'ai beau ne pas etre en accord avec certains des slides sur Phi/MIC, je ne pense pas que des anglophones utiliseraient "offload" pour traduire l'ajout d'une charge (de traduction vers CUDA, OpenCL ou autre). Offload veut dire que le CPU est decharge en travail. C'est la terminologie habituelle.
 

Je pense etre suffisamment bien place pour savoir que -- comme le dit Marc -- c'est tres dependant du probleme traite. Pour DGEMM (le code compute-bound par excellence), la BW du bus PCIE n'est pas un probleme. Par contre, pour faire des FFT sur plusieurs GPUs, on en reparlera.

"Extraction du passage parallélisable à recoder" si tu préfères.
Avec des petites vignettes de codes en blanc, et un résumé explicite en bas, histoire d'être sure que le lecteur comprenne bien.
 
Tu es tellement obsédé par cette histoire de bus que tu prêtes à une simple flèche une valeur d'argumentaire!

Dans ce genre de slides, ne pas preter a une simple fleche une valeur d'argumentaire est ce que je qualifierais de "naivete". Ceci dit, merci de m'avoir diagnostique une obsession.

Pour avoir touché le sujet de près, il semblerait que la programmation des PhysX ne soit pas aussi "facile" que le promet Intel. Et leur prévision sur OpenMP prête a sourire pour tout informaticien un tant soit peu sérieux et qui a plus de 18 ans
Par contre, leur marketing est agressif, je dois recevoir depuis 6 mois par loin d'un mail par semaine pour me vendre leur PhysX !

Beau lapsus Singman (PhysX)

Jusqu'à maintenant j'ai entendu dire que faire fonctionner un code sur Phi est aussi simple qu'une recompilation. Pour autant la performance ne sera pas au rendez-vous et il faudra réécrire une bonne partie du code. Lors de la conférence de lancement, les speedups annoncés sont en dessous de Fermi. Le summum étant le code d'exemple SAXBY qui a été développé par Intel pour MIC et qui est plus simple et plus rapide avec OpenACC et une K20X (~3X avec le compilateur CRAY).

Ooops, oui, faut remplacer PhysX par Xeon Phi !
De toute façon, pour l'instant il faut toujours ré-écrire les applications en natif. Ça pose un problème car les investissements pour faire une application en OpenACC sont lourds (en plus du matériel), et la plupart du temps ces choix sont déjà fait (-> NVidia). Choisir OpenMP (ou OpenCL ou OpenHMPP) signifie réinvestir encore. Le marché attend plutôt que le choix se porte sur un seul "langage" et que les constructeurs sortent le compilateur adapté.
Même si OpenACC essaye de fusionner avec OpenMP, j'ai bien peur que chaque constructeur garde ses "pragma" et qu'au final cela ne donne rien.

je pige pas, cette argumentaire que vs faite? si je devait rentrer dans le jeu, je dirais que les enormes supercalculateur qui utiliseront ces technologies sont forcement annéxé par leur état respectif pour la défense non? mise a part un supercalculateur je ne voit pas leur utilité faut dire.  
bref l'etat ayant son mot a dire leur point de vue est facile a comprendre je pense: puissance avant ts, et pr le codage ils trouveront facilement de la main d'oeuvre a pas cher!