Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 21 sur 22 PremièrePremière ... 1113141516171819202122 DernièreDernière
Affichage des résultats 601 à 630 sur 658

Discussion: Archi GPU et GPGPU

  1. #601
    Citation Envoyé par fefe Voir le message
    Ou une maniere d'offrir d'autres debouches aux ingenieurs de la region de Portland ?
    Sûr qu'Intel ou Intel ça fait un peu juste comme débouché

    Y'a pas d'autres boite de micro-élec dans le coin ?

  2. #602
    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

  3. #603
    C'est gros, PGI ? Histoire de me faire une idée du coût du rachat.
    Mon blog (absolument pas à jour) : Teχlog

  4. #604
    Citation Envoyé par fefe Voir le message
    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.
    Ha oui, Mentor Graphics, j'avais passé deux semaines chez eux dans une autre vie

    Donc le coin niveau micro-élec c'est un peu juste... J'imagine qu'Austin est devenu le coin le mieux pourvu aux US (et probablement dans le monde) niveau design CPU ?

  5. #605
    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.

  6. #606
    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

  7. #607
    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.

  8. #608
    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.

  9. #609
    Citation Envoyé par Møgluglu Voir le message
    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.
    Damien a les détails : http://www.hardware.fr/articles/916-...computing.html
    Mon blog (absolument pas à jour) : Teχlog

  10. #610
    Citation Envoyé par Sp1d3r Voir le message
    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...
    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 ?

    Citation Envoyé par Alexko Voir le message
    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 :
    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
    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.
    Dernière modification par Møgluglu ; 08/03/2014 à 14h19.

  11. #611
    Citation Envoyé par Møgluglu Voir le message
    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 ?
    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é.

  12. #612
    Citation Envoyé par Møgluglu Voir le message
    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.
    Je suppose qu'il faut lire GF104 ici et non GK104.

    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…
    Mon blog (absolument pas à jour) : Teχlog

  13. #613
    Citation Envoyé par Sp1d3r Voir le message
    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é.
    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.

    Citation Envoyé par Alexko Voir le message
    Je suppose qu'il faut lire GF104 ici et non GK104.
    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.

    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…
    C'est juste qu'il y a plusieurs bancs de 12 KB par SM : 4 jusqu'au GK10x et 2 à partir du GK20x, non ?
    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...

  14. #614
    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.

  15. #615
    Aie.
    C'est des gens que tu connais, non?

  16. #616
    Avec l'URL on a l'impression que c'est l'IRISA qui a fait faillite...

    nvidia ne veut pas racheter ?

  17. #617
    Citation Envoyé par vectra Voir le message
    C'est des gens que tu connais, non?
    Oui, c'est (enfin c'était) la famille.

    Citation Envoyé par newbie06 Voir le message
    Avec l'URL on a l'impression que c'est l'IRISA qui a fait faillite...

    Les financements côté université c'est pas la joie, mais on n'est pas encore au niveau de la Grèce ou l'Italie...

    nvidia ne veut pas racheter ?
    Ils ont choisi PGI.

  18. #618

  19. #619
    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...

  20. #620
    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?

  21. #621
    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...)

  22. #622
    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...

  23. #623
    Citation Envoyé par vectra Voir le message
    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...
    Si c'est comme les enchères pour les faillites de boite du monde physique, le liquidateur organise une vente aux enchères, et qui qui vient peut acheter.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  24. #624
    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?

  25. #625
    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...

  26. #626
    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...

  27. #627
    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 ?

  28. #628
    Citation Envoyé par newbie06 Voir le message
    - AMD & PathScale Join OpenACC Group ; ça vit toujours et ça va ptet vraiment devenir un standard
    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...

    - NVIDIA GK210 ; presque 3TF DP, soit à peu près comme Knight Landing
    Ouais mais c'est du bi-GPU... C'est juste intéressant en termes de densité. Et c'est toujours du Kepler.


    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 ?

  29. #629
    Je me reveille quelques mois apres, CAPS entreprise est mort
    fefe - Dillon Y'Bon

  30. #630
    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 ?

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •