Oui, c'est legit : ils ont assez de cash pour survivre jusqu'à la fin du mois, et ce depuis plusieurs années. Le MPPA-256 (Andey) existe pour de vrai depuis 2 ans. La prochaine version Bostan qui est bien plus mieux devrait sortir incessamment sous peu. C'est un processeur embarqué plus qu'un Xeon Phi, la conso du chip à 288 cœurs est entre 5 et 10W.
D'ailleurs il y a un topic dessus
http://forum.canardpc.com/threads/75...itectures-VLIW
Après l'ISC Intel publie les infos sur Knights Landing, notamment l'Optimization Guide :
https://software.intel.com/en-us/xeo...re-programming
Confirmation que la latence de la MCDRAM est supérieure à la DDR.
Vous avez bien mis des VZEROUPPER partout dans votre code comme on vous a dit ? Bah arrêtez tout :
The Intel® Xeon Phi™ processor does not have the same restrictions on mixing SSE and AVX code that Xeon processors have. Because of this, insertion of VZEROUPPER* is almost always a mistake for the Intel® Xeon Phi™ processor.
On te l'a dit c'est du x86, c'est magique ca marche partout, tout le temps. Pas besoin de recompiler, encore moins de toucher le code
Je regardais ce matin ce guide et je me posais une question bete : l'exemple DGEMM a la fin utilise des prefetch L1. Est-ce uniquement pour chauffer les TLB en cas de cross 4 KB, ou bien une autre limitation du prefetch HW L1 ?
PS - Le graphe sans legende sur les axes
Oui, et d'après la section 6.4, le prefetcher hardware ne franchit jamais les limites de 4K, quelle que soit la taille des pages. Vu qu'avec des vecteurs de 512 bits on arrive assez vite à 4K, ça vaut le coup d'avoir un software prefetch qui va accéder le TLB et aider le prefetcher hardware à démarrer sur la page suivante.
Ca semble logique, non?
C'est pas les mêmes caractéristiques attendues que pour la mémoire GPU (latence cachée par la multiplicité des threads) ?
Edit: Ah ben merde
http://www.ladepeche.fr/article/2016...-se-taire.html
Licenciements chez Intel : les salariés priés de se taire
Dernière modification par vectra ; 30/06/2016 à 11h46.
Que l'activite chip telephone portable sent le sapin on le sait officiellement depuis des mois.
Ce qui parait etrange c'est qu'Intel ferme des sites dont la specialite est le modem, activite qu'Intel n'abandonne pas. Peut-etre les employes recoivent-ils des propositions de relocalisation ?
A priori ils y a une volonté de ramener les gens vers les gros centres, ce qui suggère que l'activité se déplace mais n'est pas abandonnée.
Après, je ne sais pas ce que le management propose aux employés.
Envoyé par François
Tiens tiens: http://www.intel.com/content/dam/www...duct-brief.pdf
On y apprend qu'en fait les frequences en charge d'AVX sont 200 Mhz en-dessous des frequences annoncees par Intel. Du coup les peaks DP donnes sont faux et aucun des KNL n'atteint 3 TFLOPS (enfin si de justesse pour le 7290).
Je suis un peu surpris qu'Intel ait joue a ce jeu-la.
Bah, 2,9952 TFLOPS, pour peu que tu aies une carte mère Asus avec les fréquences spéciales échantillon de presse, ça fait plus de 3.
C'était détaillé quelque part dans le test d'Anandtech qu'à partir de Skylake, Intel baisse les fréquences max lors de load à base d'AVX, et qu'ils arrivent maintenant à le faire coeur par coeur (un coeur à -200Mhz par rapport au max si il execute de l'AVX pendant que le reste est à fond). Et c'est donc aussi sur Xeon Phi KNL.
EDIT : Je trouve plus sur anandtech, donc soit je l'ai revé (mais je pense pas) soit c'était pas sur skylake ou alors pas sur anandtech.
EDIT2 : C'était pas à partir de Skylake mais Broadwell, et c'est cité sur la review de Broadwell-E :
http://www.anandtech.com/show/10158/...e5-v4-review/3On Haswell, one AVX instruction on one core forced all cores on the same socket to slow down their clockspeed by around 2 to 4 speed bins (-200,-400 MHz) for at least 1 ms, as AVX has a higher power requirement that reduces how much a CPU can turbo. On Broadwell, only the cores that run AVX code will be reducing their clockspeed, allowing the other cores to run at higher speeds.
Mais du coup sur une machine qui fait tourner du code avec de l'AVX tout le temps, ça réduit pas mal les perfs.
En ésperant que sur KNL, c'est un coeur à la fois qui baisse de fréquence et pas les 72 coeurs quand il y en a un qui fait tourner de l'AVX.
Pour KNL, ils ont donne des chiffres qui etaient plus hauts, en accord avec une frequence de base maintenue, c'est bien le souci.
C'est du Turbo 2.0 pas 3.0, donc meme frequence pour tout le monde.Mais du coup sur une machine qui fait tourner du code avec de l'AVX tout le temps, ça réduit pas mal les perfs.
En ésperant que sur KNL, c'est un coeur à la fois qui baisse de fréquence et pas les 72 coeurs quand il y en a un qui fait tourner de l'AVX.
C'est pas comme si c'était un processeur fait pour faire tourner de l'AVX-512 sur tous les cores en même temps, non plus.
Ca te fait pas rever 72 coeurs Silvermont sur une puce?
Bon, les news des dernières semaines, a priori sans rapport entre elles :
- Intel débauche Raja Koduri pour diriger un "Core and Visual Computing Group" avec l'ambition de développer des GPU séparés.
- Knights Hill est annulé, et ses descendants le seraient aussi.
Donc nouveau rebondissement : Xeon Phi est mort, vive Larrabee.
Il va falloir rebooter ce topic.
Bien entendu. On n'a absolument aucune idée si les autres projets de Xeon Phi seront maintenus et sinon par quoi ils seront remplacés. Une seule chose est certaine à ce stade : ce sera du x86.
https://www.top500.org/news/intel-du...ine-uncertain/And when asked to clarify what the future HPC processors would look like, the company would only say they that would be based on the “Intel Architecture” in order to support legacy codes.
Pendant ce temps, la DOE retarde le planning de son prochain supercalculateur et la Chine envahit le Top500. Mais ça compte pas, Linpack est soudain devenu un benchmark tout pourri.
Bon alors ca ne sortira jamais, larrabee du futur ?
(Le JELB en lien, j'ai honte ).
Dans le Knight's Landing, y'avait quand même accès à de la mémoire 3D haute performance (>500 Go/s comme-même) proche du processeur, sans même devoir passer par un bus PCI-e.
Ca me désole de voir ça disparaitre, mais bon je ne bosse plus sur mon sujet de thèse après tout...
Si tu appelles le GPU un processeur, tu as la même chose chez Nvidia et AMD.
Et pour communiquer entre différents Xeon Phi ou différents GPU dans un supercalculateur, tu ne passes pas par PCIe mais par un interconnect propriétaire : OmniPath et NVLink, respectivement. Un partout, balle au centre.
Mais moi c'était pour du traitement temps réel de données acquises, qui arrivent en mémoire CPU.
Oui enfin elles n'y arrivent pas toutes seules les données en mémoire, il faut bien les transférer depuis le matos d'acquisition, en passant par un bus qui n'est pas à 500 Go/s, lui (de mémoire, du simple Gigabit Ethernet...)