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)