Un compilateur pour GPU

C'est vraiment énorme, je songe à une distribution Linux compilée pour le GPU... De quoi redonner de la pêche aux netbooks pénalisés par un petit processeur Atom mais dotés d'une bonne carte graphique.

hé, t'en va pas trop loin..
entre un logiciel et un OS, il y a un gouffre. Pour un OS, il faut un proco très généraliste, avec les jeux d'instruction qu'il faut. je ne pense pas que la souplesse d'une programmation sur CUDA 1.0 ~1.3 (la moyenne actuelle) te permettent d'obtenir cela. les logiciels 128x plus performante sont surement trié et très parralélisable dans leur fonctionnement à la base...

par contre, la news est géniale. Si ça se vérifie, c'est l'avènement assuré du GPGPU. Et avec Cuda 3.0 sur Fermi et son architecture mémoire unifié, la souplesse de programmation monte d'un sérieux niveau. On ne peut qu'applaudir...

Super, est si ça marche bien pourkoi pas directement l' implementé
dans le noyaux de l' os

ge pense kon devré augmenter la vitesse du systeme dexploitation avec ca !

L'utilité directe pour l'OS est loin d'être évidente. Ce n'est pas lui le plus gros consommateur de temps processeur les amis.

Le gain sera plus appréciable pour des applications ciblées ayant une grosse consommation de virgule flottante.

3D et décodage audio/vidéo c'est une autre histoire en revanche, et "Flash".

Bientôt un compilateur qui "accélère internet" ? :-)

d'ailleurs, où est-ce qu'il a vu une "bonne carte graphique" sur un netbook?

La seule méthodologie de programmation qui permet de tirer parti d'un GPU est la programation par flux.. En général, porter les algorithmes/programmes est décevant parceque les programmeurs ne prennent pas le temps de se pencher sur les spécificités de l'architecture des GPUS: il n'y a pas de cache (1mb pour 512 cores?), et la programmation concurente a tendance a ne pas scaler de facon linéaire avec le nombre de cores.. Le manque de cache et la latence de la DDR5 en particulier ont une conséquence très lourde sur les programmes: Les structures arborescentes et les graphes sont très lents, car les accès mémoire lors des parcours forment des chaines dépendantes de l'accès précédent... Souvent, la solution d'accès séquencielles bourrin paye plus en termes de performances, si le dataset n'est pas trop gros... Mais bon wait&see, ils ont peut être trouvé la solution miracle qui fait le boulot du programmeur à sa place...

Hum, je crois que le papier a été mal compris. Il est disponible sur la page de l'un des auteurs ( http://www.eecs.ucf.edu/~zhou/pldi10.pdf ).
Le compilateur présenté optimise les fonctions de calcul intensif (multiplication de matrices, transposition, etc.) et génère un code optimisé pour GPU.
Il n'est pas directement utile pour les programmes généralistes (OS, navigateur web).
La mention de la dépêche "permettant à n’importe quel programme tournant sur un CPU de tirer parti de la puissance de calcul des GPU" est complètement à coté de la plaque. Ce compilateur ne permet pas l'extraction/la reconnaissance des fonctions de calcul intensives dans un code source quelconque. C'est toujours au programmeur de spécifier ces fonctions et de les faire passer dans un compilateur distinct.

les netbook avec nVIDIA Ion ne sont pas si ridicule... (même si ça reste tendu pour jouer)

Et c'est d'autant plus vrai que l'immense majorité des traitements de l'OS est basé sur l'attente logicielle d'une action matérielle : souris, clavier, périphériques... donc, difficile d'envisager un gain quelconque avec des GPU très spécialisés.

En revanche, la puissance de calcul brute disponible pourrait être mise à profit (cf Nvidia et son Tesla) pour accélérer notoirement des applications comme celles de CAO/DAO/PAO, les encodeurs/Décodeurs audio vidéo... Enfin bref, tout ce qui nécessite d'exécuter de gros calculs à la volée qui plombent brutalement les performances.

Je voudrais me joindre a Nystep et ajouter que l'utilisation de GPU ne s'applique vraiment que dans un contexte SIMD. En gros on applique de façon indépendante une même opération a une vaste collection de données elles aussi indépendante. A la seconde ou il y a des branchements, conditions ou dépendances... ben... tes beaux TFlops fondent comme neige au four à micro-ondes.
Donc ajouter des grosses matrices, oui! Répondre à un clic de souris, ou compiler un code source, non!!!!

Effectivement, l'article fait des résumés assez abusifs de l'article original en anglais (merci razibuzouzou d'ailleurs). Ce que le compilateur fait, c'est seulement prendre un code déjà conçu pour GPU (de façon naïve et non optimisée) en un code hautement optimisé. En soit c'est extrêmement intéressant pour le GPU Computing car ça prends vraiment beaucoup de temps d'optimiser les kernels, surtout que cela implique une solide connaissance du GPU utilisé et que la version optimisée n'est pas portable car dépendante du hardware. Avec ce nouveau compilateur, à partir d'un code simple et portable, on pourra obtenir un code optimisé !

Par contre, la partie qui est de traduire un algo pour CPU en algo par GPU en utilisant du massivement parallèle n'est pas réalisée par le compilateur, mais bien par le développeur ! Globalement, il sera utile pour les personnes (comme moi) qui font du GPU Computing et cherchent à faire tourner sur GPU des calculs très longs, et non pour faire de l'événementiel ou de l'interruption.