Pas beaucoup, Solar world, Mentor graphics, PGI et c'est pas exactement la meme chose. Nvidia a qq employes depuis qq annees. HP a Vancouver WA sur l'autre rive de la Columbia mais faut vouloir faire des imprimantes .
Il y a plein de boites qui contractent pour Intel mais c'est plutot le cote manufacturing, et quelques petites startups.
fefe - Dillon Y'Bon
C'est gros, PGI ? Histoire de me faire une idée du coût du rachat.
Mon blog (absolument pas à jour) : Teχlog
C'est tellement la crise qu'il n'y a plus personne dans la silicon valley ? Il y a toujours Oracle/Sun, Nvidia, MIPS (il parait qu'il sont vivants), et puis euh... Tilera...
Et Xilinx et Altera aussi ils font des CPU mous.
Il y a encore pas mal d'activite dans la silicon valley, surtout cote startups. Mais oui c'est a Austin qu'il y a le plus de jobs en ce moment, essentiellement des grosses boites. Dans les moins connus il y a Ralleigh NC et San Diego CA, mais qui souffrent de problemes un peu similaires a Portland. Greater Boston area reste un centre de high tech assez important aussi.
Si je sample ma boite a pm Linkedin c'est dans l'ordre Austin, Silicon Valley, Ralleigh, San Diego, Boston...
fefe - Dillon Y'Bon
Sur Maxwell, le cache L1 de données a été séparé de la shared memory, pour être unifié avec le cache de texture. Mais je n'ai pas trouvé d'info sur la taille de ce cache unifié. J'ai raté quelque chose ?
Sur Kepler on aurait 48KB de cache de texture par SM. Mais vu que Nvidia reste étrangement silencieux sur cette partie des specs, peut-être que le cache texture a rétréci sur Maxwell ?
D'ailleurs il sert à quoi ce cache ? Sur Kepler, le L1 ne servait déjà qu'aux données thread-local. Les données constantes passaient par le cache de texture, et les autres bypassaient le cache L1 (parce qu'il ne maintient pas la cohérence).
Au final, j'ai l'impression qu'ils ont surtout changé les étiquettes, et que le rôle du L1D est anecdotique.
CUDA 6 arrive, avec l'Unified Memory.
https://devblogs.nvidia.com/parallel...ory-in-cuda-6/
Pas de miracle niveau performance, mais quand même quelques cas d'utilisations qui peuvent se révéler intéressant...
An important point is that a carefully tuned CUDA program that uses streams and cudaMemcpyAsync to efficiently overlap execution with data transfers may very well perform better than a CUDA program that only uses Unified Memory. Understandably so: the CUDA runtime never has as much information as the programmer does about where data is needed and when! CUDA programmers still have access to explicit device memory allocation and asynchronous memory copies to optimize data management and CPU-GPU concurrency. Unified Memory is first and foremost a productivity feature that provides a smoother on-ramp to parallel computing, without taking away any of CUDA’s features for power users.
Damien a les détails : http://www.hardware.fr/articles/916-...computing.html
Mon blog (absolument pas à jour) : Teχlog
Tu as pu jouer avec ? À part l'intégration propre dans CUDA, ça apporte quelque chose par rapport aux runtimes développés chez vous ?
Merci ! Donc le texture cache aurait bien régressé à 12KB, et le L1D aussi du même coup.
Edit: et Damien confirme que le L1D ne gère pas les spills de registres sur Maxwell première génération. Donc en fait ils n'ont pas déplacé le L1D, ils l'ont juste supprimé !
Alors, en fait d'améliorations :Donc en gros le GM107 est au GK110 ce que le GK104 était au GF100 : le même design débuggé, optimisé, et appliqué à l'entrée ou milieu de gamme.Voici en résumé les améliorations :
- augmentation du débit des opérations logiques et sur les entiers -> qui avait diminué sous Kepler par rapport à Fermi
- réduction de la latence des unités de calcul
- possibilité d'utiliser plus de 63 registres par thread (jusqu'à 255) -> comme le GK110
- la mémoire partagée totale passe de 48 à 64 Ko par SMM -> au dépens du L1
- le texture cache peut faire office de L1D comme sur le GK110
- support du Dynamic Parallelism comme sur le GK110
Dernière modification par Møgluglu ; 08/03/2014 à 14h19.
Pour l'instant, je n'ai pas pu jouer avec mais de ce que je lis, ça n'apporte rien pour un programmeur qui a optimisé son code en recouvrant calcul/comm. Ça apporte surtout de la lisibilité et quelques astuces comme celle de la liste chaîné qu'il faudra éprouver en pratique. La copie Host / GPU ou GPU / Host est implicite mais elle est toujours là et il n'y a pas de prefetch.
Ils ont prévu de supporter le prefetch dans le futur, donc c'est une interface qui révélera tout son potentiel plus tard. Encore faut-il savoir quand et quoi prefetcher et je ne pense pas que ce soit une tâche aisée...
L'avantage d'un runtime basé sur l'ordonnancement de tâches avec dépendances, c'est principalement qu'il a une vision très clair de ce qui sera exécuté, donc le prefetch des données peut vraiment être optimisé.
Mon blog (absolument pas à jour) : Teχlog
D'accord. Donc du point de vue du runtime ou du compilateur, l'Unified Memory est plus un nouvel outil bas niveau pour les cas où on manque d'infos sur les zones mémoires accédées - par exemple si on n'a pas pu prouver l'absence d'aliasing.
Si si, GK104. Il suffit de regarder le jeu d'instructions pour voir que GK104 est bien plus proche du GF100/110 que du GK110... Une sorte de tick-tock à la Nvidia, quoi.
C'est juste qu'il y a plusieurs bancs de 12 KB par SM : 4 jusqu'au GK10x et 2 à partir du GK20x, non ?Mais d'après Damien le texture cache a toujours été de 12 ko, alors qu'on peut lire ailleurs qu'il faisait 48 ko sur Kepler. Donc je ne sais pas trop…
http://www.hardware.fr/articles/916-...m-details.html
Edit: ah non, ce sont bien des caches indépendants et pas des bancs. Ce qui expliquerait que personne n'a réussi à exploiter plus de 12 KB parmi les 48 KB prétendus. Quels petits farceurs chez Nvidia...
C'est ici la section petites annonces ?
Le compilateur OpenACC de CAPS est à vendre.
État neuf. Vendu avec ou sans son équipe de dev d'origine. Faire offre.
C'est moche
Qu'est-ce que tu veux, les compilateurs, ça paie plus...
Sinon on pourrait lancer un Kickstarter pour faire une offre groupée, acheter le code et le rendre open-source.
En échange de goodies comme des boîtes du logiciel dédicacées, des brouillons de specs avec du rouge partout, des bug trackers, des T-shirts HMPP...
Il faudrait récolter combien pour racheter openAAC ?
Et au niveau des bibliothèques tierces utilisés, il n'y a rien d'incompatible avec de l'open source?
A priori ça sera vendu aux enchères. Moi je monterai jusqu'à 51€.
Concernant l'IP tierce, je ne sais pas si c'est facilement opensourçable, c'était plus pour la blague.
Sinon OpenACC est un standard comme OpenMP. Là il s'agit d'un compilateur compatible avec le standard.
(Bon, en fait, OpenACC résulte de l'unification des systèmes de directives propriétaires respectifs de CAPS, PGI et Cray. Donc en l'occurence c'est plutôt le standard qui a été fait pour être compatible avec le compilo existant...)
Ca se déroule comment, ces enchères?
Le liquidateur est qualifié pour démarcher auprès des sociétés intéressées, qui à mon avis sont plus ou moins toutes sur Austin/SV/etc...
Ben dans ce cas là, pourquoi pas mettre 51 euros et placer le projet en OpenSource après?
Enfin, j'imagine que les employés de la boîte y ont pensé d'eux-mêmes avant nous, non?
Oui, c'est ce qui se passerait dans le pire, ou le meilleur des cas, suivant le point de vue.
Mais avant d'en arriver là, il y a toujours l'espoir de trouver un repreneur sérieux qui ait un peu de pognon à investir pour relancer la machine...
Bin on l'espère tous aussi, et surtout que ça ne soit pas racheté par une random entreprise qui va garder ça sous la main pour tenter de le revendre et en fin de compte faire crever le truc.
Ca serait bien que ça passe en open-source dans le pire des cas, pour que la communauté puisse développer ça à son rythme. Visiblement, cette communauté existe, vu qu'un standard a été établi pour coller à ce compilateur...
En vrac :
- AMD & PathScale Join OpenACC Group ; ça vit toujours et ça va ptet vraiment devenir un standard
- NVIDIA GK210 ; presque 3TF DP, soit à peu près comme Knight Landing
Et sinon ça fait pleurer personne ça ?
Intéressant, ça fait une alliance NVIDIA - AMD (OpenACC) contre Intel (OpenMP 4.0)... Reste à savoir lequel des deux va devenir un standard...
Pathscale ça fait longtemps qu'ils auraient du s'y mettre. Ils continuaient à travailler avec les directives HMPP, alors que même CAPS était passé à OpenACC. Et maintenant, ils n'ont plus le choix...
Ouais mais c'est du bi-GPU... C'est juste intéressant en termes de densité. Et c'est toujours du Kepler.- NVIDIA GK210 ; presque 3TF DP, soit à peu près comme Knight Landing
Et sinon ça fait pleurer personne ça ?
Ils arrêtent vraiment ou c'est juste le site web qui est en chantier ?
Ils font quoi avec les "licences" en cours, genre icc qu'on a installé un peu partout ?
Je me reveille quelques mois apres, CAPS entreprise est mort
fefe - Dillon Y'Bon
RIP CAPSe. Je n'ai pas de nouvelles récentes mais je ne crois pas que ça puisse repartir à ce stade.
Tu t'en es rendu compte maintenant parce que tu as reçu une pile de CV sur ton bureau ?