IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

CUDA Discussion :

CUDA et LLVM, des nouvelles


Sujet :

CUDA

  1. #1
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    25 958
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 25 958
    Points : 181 579
    Points
    181 579
    Par défaut CUDA et LLVM, des nouvelles
    Le compilateur officiel de NVIDIA pour ses extensions GPGPU aux langages C et C++, nvcc, n’est plus la seule option pour compiler ce code CUDA depuis la version 4.1. Depuis ces quelques années, cette contribution au compilateur libre LLVM fait son bout de chemin. L’idée est de générer du code PTX, c’est-à-dire l’assembleur utilisé sur les GPU NVIDIA, traduit par les pilotes officiels en instructions selon le GPU.

    La semaine dernière, deux nouveautés sont arrivées dans les dépôts de LLVM et Clang au sujet de CUDA. La première est un guide rapide pour compiler le compilateur et commencer à l’utiliser, surtout à destination de chercheurs et développeurs de LLVM, notamment pour les aider à développer des passes d’optimisation spécifiques aux GPU. Pour ce faire, une série de modifications au niveau des sources de LLVM est nécessaire (l’implémentation s’oriente comme nvcc, avec du code pour l’hôte et le GPU mélangé dans un même fichier).

    Ce document explicite notamment les optimisations déjà réalisées par LLVM et les modifications CUDA pour améliorer la performance sur les GPU. Notamment :
    • la réduction des redondances dans le calcul d’expressions mathématiques : si x=b*s a déjà été exécuté, l’affectation y=(b+1)*s sera réécrite comme y=x+s, ce qui évite de calculer le facteur b+1 en sus de la multiplication ;
    • l’inférence de l’espace mémoire à utiliser pour une variable (à choisir entre mémoires globale, constante, partagée et locale) ;
    • le déroulement des boucles et l’extension en ligne des appels de fonction plus agressifs que sur du code à destination de CPU, puisque tout transfert de l’exécution sur un GPU est bien plus coûteux que sur un CPU (tout saut, toute condition nuisent fortement à la performance) ;
    • l’analyse du recouvrement entre pointeurs, dans le cadre d’une passe généralisée à tout LLVM (bien que cette partie spécifique aux GPU n’est pas encore intégrée) ;
    • l’évitement de divisions lentes sur soixante-quatre bits, par manque de circuits spécifiques pour cette opération sur les GPU NVIDIA (elles sont remplacées, autant que possible, par des opérations sur trente-deux bits).

    Une bonne partie de ces optimisations a eu des contributions de la part de Google, qui pourraient sembler quelque peu inattendues. Leur objectif est de développer une plateforme à la pointe de la technologie pour la recherche sur la compilation pour GPU et le calcul scientifique de haute performance en général. Leurs premiers résultats, présentés par Jingyue Wu[/URL], indiquent que leurs avancées sur LLVM font aussi bien que le compilateur de NVIDIA, nvcc, sur certains tests… et vont parfois jusque cinquante pour cent plus vite que le code produit par nvcc ! Ceci s’accompagne d’un gain de huit pour cent en moyenne sur le temps de compilation (sans véritable intégration à Clang, puisque la compilation s’effectue en plusieurs phases bien séparées — GPU et CPU —, ce qui fait perdre pas mal de temps).

    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  2. #2
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 711
    Points : 4 405
    Points
    4 405
    Par défaut
    Arf.

    Google qui travaille sur CUDA ne me semble pas une bonne nouvelle. (Bien sur c'est une bonne nouvelle pour ceux qui utilisent CUDA ^^).

    CUDA existe seulement parce qu’il est arrivé avant OpenCL / DirectCompute, et renforcer une "version proprio d'OpenCL" ne me semble clairement pas bon.

    J'aurais préféré entendre que Google bosse sur un compilo OpenCL (ou DirectCompute).

    Belle prouesse technique tout de même.

  3. #3
    MikeRowSoft
    Invité(e)
    Par défaut
    Cool, la librairie OpenCL était déjà annonciatrice.
    PhysX à OpenCL est beaucoup trop simple, la librairie CUDA aurait été la base...

    En se qui concerne la réflexion sur la différence CPU et GPU je voudrais bien connaitre la réponse d'Intel vis-à-vis de leur projet Larrabee.

    Les unités de traitements des textures, sont utilisés en dehors des jeux vidéos et du graphisme en général?
    Tracer un "trait" est devenu calculer le "trait" sans l'afficher je dirais, presque du "preprocessing"...
    Dernière modification par MikeRowSoft ; 16/11/2015 à 12h13.

  4. #4
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 214
    Points
    2 214
    Par défaut
    Citation Envoyé par Iradrille Voir le message
    CUDA existe seulement parce qu’il est arrivé avant OpenCL / DirectCompute, et renforcer une "version proprio d'OpenCL" ne me semble clairement pas bon.
    DirectCompute, c'est pas trop open non plus...

    Citation Envoyé par MikeRowSoft Voir le message
    Cool, la librairie OpenCL était déjà annonciatrice.
    PhysX à OpenCL est beaucoup trop simple, la librairie CUDA aurait été la base...
    Quel rapport avec PhysX ?

  5. #5
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    25 958
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 25 958
    Points : 181 579
    Points
    181 579
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    DirectCompute, c'est pas trop open non plus...
    Dans un certain sens, quand même plus que CUDA, vu que ça n'est pas limité à un fabriquant de GPU — différence qui commence à s'estomper, notamment avec des projets comme celui-ci (ou l'implémentation de CUDA dans Nouveau : http://blog.developpez.com/dourouc05...-souvre-a-cuda).
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  6. #6
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Quel rapport avec PhysX ?
    Les pilotes ou drivers (en bon "english"), l'un n'empêche pas l'autre.

    J'ai récemment découvert, sur mon poste informatique réservé à cela, qu'il était possible d'installer deux pilotes différent pour deux cartes graphiques différentes mais de même constructeur sous Linux. Mais avant que je procède à cela le x.org à bogué et impossible de récupéré comme un novice, donc sa c'est arrêté là,puis je l'ai désinstaller (bien que le secteur de boot du grub y soit resté, comme pour les clés USB, merci Rufus et les autres outils pour leur aide pour retirer se genre de truc).

    Testé sous Windows, étrangement un pilote d'un constructeur veut être gestionnaire de toutes les cartes graphiques du même constructeur de "puces". Donc Geforce 610 GT et Geforce 8200 n'ayant pas toujours des compatibilités communes, l'a aussi sa c'est arrêté là...

Discussions similaires

  1. [War] Gestion des nouvelles versions
    Par hugo123 dans le forum Tomcat et TomEE
    Réponses: 2
    Dernier message: 06/07/2006, 09h10
  2. Installer des nouvelles polices
    Par Furius dans le forum Windows XP
    Réponses: 15
    Dernier message: 01/01/2006, 13h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo