Tous les articles par Bertrand

CUDA

Voici la seconde partie de mon article sur les GPU.
Celui-ci vous permettra de découvrir CUDA de NVIDIA

1      Présentation

CUDA ou Computer Unified Device Architecture est une librairie de développement créée par NVIDIA en 2007. Celle-ci associée à une carte graphique compatible, permet d’utiliser la puissance de calculs des GPU d’architectureG80 et plus de NVidia (à partir des GeForce 8800 et déclinaisons).
Par abus de langage nous parlerons aussi de langage CUDA.
CUDA est aussi le premier langage à exploiter l’unification des shaders : les processeurs de la carte ne sont pas différentiés en unités pour le traitement des vertex ou des fragments, chacun de ceux-ci peut être assigné à n’importe quelle tâche.

L’API CUDA supporte plusieurs langages tels que le C, le C++ et le Fortran.
Ces trois langages peuvent être utilisés simultanément pour écrire diverses fonctions exécutées par le GPU.

Il existe cependant des « wrapper », des passerelles, servant de liaison entre ces langages bas-niveau et des langages de plus haut niveaux tels que Python, Java et .Net.

CUDA est constitué d’un pilote (driver), déjà intégré aux drivers les plus récents, d’un runtime, et de quelques librairies.

Les différents composants de CUDA
Les différents composants de CUDA

Il existe 3 niveaux de programmation pour CUDA, chacune disposant de sa propre API :

–       Utilisation d’une librairie externe.
Celle-ci, possède le code de toute les fonctions à exécuter par le GPU, et sert de liaison entre le programme et le GPU.
Le développeur ne peut utiliser que certaines fonctions prédéfinies, et ne peut contrôler directement le GPU.
Les deux librairies les plus connues sont CUBLAS qui offre un ensemble d’éléments pour réaliser des calculs d’algèbre linéaires sur le GPU, ainsi que CUFFT qui permet le calcul de transformée de Fourrier.

–       l’API de haut niveau : l’API CUDA Runtime ou appelée plus communément C for CUDA.
Cette API est implémentée « au dessus » de l’API bas niveau. Chaque appel à une fonction du runtime est décomposé en instructions plus basiques gérées par l’API driver.
Ces 2 API sont exclusives : le programmeur doit utiliser soit l’une soit l’autre. Il est impossible de mélanger des appels de fonctions de l’une et de l’autre.
Lorsque l’on parle d’API de haut niveau, il convient de relativiser : l’API runtime reste ce que beaucoup considèreraient comme déjà de très bas niveau. Cependant elle offre des fonctions bien pratiques pour l’initialisation ou la gestion des contextes.
Cette API sera la plus couramment utilisée.

–       l’API de bas niveau : l’API CUDA Driver.
Cette API est plus complexe à gérer, elle demande plus de travail pour lancer un traitement sur le GPU, mais en contrepartie elle est plus flexible, offrant un contrôle supplémentaire au programmeur qui le désire.
Cette API a l’avantage de pouvoir charger des portions de code en tant que module à partir de code binaires CUDA ou de code assembleur, et permet aussi d’inspecter les paramètres, …
Cette API est beaucoup plus difficile à écrire, à débugger et nécessite beaucoup plus de lignes de code à écrire, mais elle offre de meilleure performances.

Les API Runtime et Driver sont capables toutes les deux de communiquer avec des ressources OpenGL ou Direct3D. L’utilité est évidente : CUDA pourrait être utilisé pour générer des ressources (géométrie, textures procédurales, etc.) qui seraient ensuite passées à l’API graphique ou à l’inverse on pourrait imaginer que l’API 3D pourrait envoyer le résultat du rendu à CUDA qui serait dans ce cas utilisé pour effectuer un post traitement. Les exemples d’interactions sont nombreux et l’avantage est que les ressources restent stockées dans la mémoire RAM du GPU sans avoir à passer par le goulot d’étranglement du bus PCI-Express.

CUDA est fourni avec un « émulateur » : le code devant s’exécuter sur le GPU est en fait exécuté sur le GPU. Les performances sont alors bien moindres, mais permettent de débugger l’application et de tester celle-ci lorsqu’on ne dispose pas de GPU compatible.

Présentation d’un GPU

Mon stage de fin d’études au Centre National d’Etudes Spatiales portant sur les GPU, je vous propose une série d’articles traitant de ce thème.

Depuis ma première publication le 07 octobre, j’ai complété mon article, en lui rajoutant quelques précisions.

1.1         Historique

1.1.1        Le CPU

Les ordinateurs personnels et les stations de travail professionnel sont des systèmes autonomes dédiés à l’exécution d’applications logicielles. Au cœur de ces systèmes se trouve un microprocesseur central, ou CPU (Central Processing Unit), qui interprète les instructions et traite les données qui constituent ces applications. C’est lui qui a la charge de l’ensemble des calculs.

1.1.2        Evolution du CPU

Dans les années 80, de nouveaux besoins sont apparus nécessitant le traitement de données de plus en plus volumineuses, notamment dans les domaines de l’imagerie, de la vidéo ou du son, encore appelé multimédia. Les principales applications à l’origine de ces besoins sont logiciels professionnels de conception assistée par ordinateur (CAO) et les jeux vidéos.

Les applications multimédia s’appuient sur des algorithmes de nature très différente des applications dites « classiques » (bureautique par exemple). Alors que ces dernières traitent peu de données mais avec une logique de traitement complexe impliquant beaucoup d’interactions, de re-bouclages et de branchement conditionnels (si… alors…), les applications multimédia nécessite d’appliquer des algorithmes plus linéaires mais à de gros volumes de données. On parle de calcul vectoriel.

Les architectures des microprocesseurs se sont donc adaptées pour traiter aux mieux ces nouvelles problématiques en proposant des fonctionnalités dédiées aux applications multimédia, sous formes d’instructions spécifiques implantées au sein du processeur : MMX pour les processeurs Intel Pentium, 3D Now ! pour les processeurs AMD Opteron. Ces nouvelles instructions, qui permettent d’appliquer la même opération à plusieurs données à la fois, ont permis d’améliorer les performances des applications faisant appel à des algorithmes vectoriels, ce qui a contribué à leur succès.

Ces nouveaux microprocesseurs ont permis d’apporter des GFLOPS [1] aux ordinateurs de bureau ainsi que des centaines de GFLOPS aux serveurs. Ces nouvelles instructions et l’augmentation de performances associée ont permis d’enrichir la qualité des applications en élargissant les fonctionnalités offertes tout en améliorant les interfaces utilisateurs. Les utilisateurs, à leur tours, habitués à ces continuels progrès exigent toujours plus d’améliorations, aussi bien sur la perception des performances que sur les effets visuels, ce qui crée un cycle positif pour l’industrie informatique.

Pour répondre au besoin croissant de performance, la plupart des développeurs de logiciels ont compté sur les évolutions du matériel pour exécuter plus rapidement leurs programmes. Ainsi le même logiciel fonctionne plus rapidement sur chaque nouvelle génération de processeurs. Malheureusement cette course s’est ralentie depuis 2003 en raison de problèmes limitant l’augmentation du nombre d’instructions qu’un CPU peut exécuter par seconde (on parle de fréquence d’horloge). Ces problèmes sont principalement liés à la miniaturisation des composants (finesse de gravure) et à l’augmentation du nombre de transistors dans un microprocesseur induisant un dégagement de chaleur de plus en plus important ainsi que des interactions électromagnétiques, entrainant engendrant une augmentation de consommation électrique.

Pour palier aux problèmes de miniaturisation, plusieurs solutions ont été trouvées :

  • Combiner plusieurs processeurs en un seul, les tâches à réaliser sont alors réparties entre les unités de calcul qui le composent. C’est ce que l’on appelle le « multi-cœur ». Cette nouvelle technologie a eu un impact important sur le développement logiciel.
  • Adjoindre un microprocesseur spécifique dédié à l’accélération des applications les plus gourmandes, à savoir les applications multimédia. Cette approche a été possible de part la spécificité algorithmique (calcul vectoriel) de ces derniers. C’est ce qui deviendra le GPU (Graphic Process Unit).

[1] GFLOPS : se lit Giga Flops. Signification : milliards d’opérations à virgule flottante par seconde.
Il s’agit de l’unité de référence pour calculer la vitesse d’un processeur.

VirtualBox 2.2.2 – Problème de mises à jour et de désinstallation

Ayant installé il y a une semaine VirtualBox 2.2.2, j’ai été amené aujourd’hui à installer la mise à jour 2.2.2-46594.

Malheureusement lors de l’installation, l’ancienne version ne voulait pas se désinstaller et il m’était impossible d’installer le nouveau correctif. Continuer la lecture de VirtualBox 2.2.2 – Problème de mises à jour et de désinstallation

Installer Kaspersky AntiVirus sous Windows Server 2008

Installer Kaspersky AntiVirus sous Windows 2008 Server

Il y a de cela plusieurs mois, mes besoins m’ont poussés à installer 4Go de RAM sur mon ordinateur.
Mon système d’exploitation de l’époque, Windows XP, du fait du 32bit, ne pouvait les gérer pleinement. J’ai alors décidé de me tourner vers un système 64 bits.
Mes possibilités étaient les suivantes : Windows XP 64 bits, Windows Vista 64 bits ou Windows Server 2008 64 bits.

Mon premier choix se portait vers Windows XP 64, pour sa « légèreté » comparé à Vista. Malheureusement certains drivers de mon ordinateurs n’étaient pas disponibles pour ce système. Pour d’autres, je devais installer des drivers spécifiques à Vista (les drivers WDM étant les mêmes que ce soit pour XP ou Vista). Du fait de mon problème de driver, je n’ai pas opté pour ce système.
Pour des raisons de performances, j’ai finit par me tourner vers windows Server 2008, que j’ai adapté pour une utilisation workstation : celui-ci d’après les articles sur internet étant bien plus rapide que Vista.

Très vite s’est posé la question du choix de l’AntiVirus.

Utilisateur de Kaspersky AntiVirus, j’ai décidé de l’installer sur Windows Server 2008.
Lors de l’installation, j’ai obtenu le message d’erreur suivant :

kav-install
Après vérification sur le site de l’éditeur, aucune version n’existe pour Windows 2008.
Ceci est un comble, du fait que Vista et Server 2008 possèdent le même noyau.

Vous trouverez ci-dessous la procédure à suivre pour contourner ce message d’erreur, imposé par l’éditeur.

Continuer la lecture de Installer Kaspersky AntiVirus sous Windows Server 2008

Benchmark : Windows Vista – Windows 7 – Ubuntu

Actuellement nous pouvons constater l’apparition d’articles traitant des performances de Windows 7.
Si ces articles sont très positifs, qu’en est-il de la comparaison entre Windows 7 en version 32 bits et 64 bits? Windows 7 se voulant dédié au tout public, que vaut-il comparé à une distribution Linux grand public, telle qu’Ubuntu?

Pour répondre à ces questions, notre confrère de Tux Radar a réalisé toute une série de tests :
– Windows 7 est-il plus facile à installer?
– Windows 7 est-il plus rapide au démarrage et à l’arrêt?
– Windows 7 est-il plus rapide pour la copie de fichiers?

Je vous invite à lire le test complet (en anglais).

Convertir une image virtuelle VMWARE (vmdk) Windows au format Virtual Box (vdi)

Convertir une image virtuelle VMWARE (vmdk) Windows au format Virtual Box (vdi).

Par défaut, une image VMWare (vmdk) ne peut pas être utilisée telle quelle par VirtualBox.
Il faut effectuer quelques modifications dessus, pour les rendre compatibles.

Continuer la lecture de Convertir une image virtuelle VMWARE (vmdk) Windows au format Virtual Box (vdi)