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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

[HPC] Google contribue à un compilateur libre pour CUDA
Leurs passes d'optimisation dans LLVM peuvent battre le compilateur de NVIDIA

Le , par dourouc05

37PARTAGES

6  0 
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).

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Iradrille
Expert confirmé https://www.developpez.com
Le 16/11/2015 à 11:08
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.
1  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 16/11/2015 à 13:11
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 ?
0  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 16/11/2015 à 13:26
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).
0  0 
Avatar de
https://www.developpez.com
Le 16/11/2015 à 14:40
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à...
0  1 
Avatar de
https://www.developpez.com
Le 16/11/2015 à 11:49
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"...
0  2