L'avenir des SGBD est-t-il dans les processeurs graphiques ? Une équipe y croit

Version imprimable

02/09/2010, 15h03
Idelways

L'avenir des SGBD est-t-il dans les processeurs graphiques ? Une équipe y croit

L'avenir des SGBD est-t-il dans les processeurs graphiques ?
Une équipe y croit et arrive à trier 1 milliard d'entiers par seconde

Le projet « Back 40 Computing » a pour but de fournir un ensemble de codes destinés à réaliser de très hautes performances grâce aux processeurs graphiques (GPU).

Ce projet est dirigé par Duane Merrill, un chercheur à l'université de Virginie.

La version en cours est l'implémentation existante la plus rapide de l'algorithme de tri par base (en anglais : Radix sort) utilisant des processeurs graphiques.

Elle est capable de trier 1 milliard de clés par seconde avec une carte graphique GTX480 de NVidia.

Déjà, des équipes travaillent pour combiner la puissance de calcul des GPU avec PostegreSQL en utilisant CUDA, une technologie qui permet de programmer les GPU en C.

Le code source et la documentation sont d'ores et déjà disponibles sur Google Code.

Tout simplement impressionnant.

Il ne reste plus à espérer que les fruits de ce projet seront à la base d'une avancée majeure dans l'univers des SGBD.

:fleche: Qu'en pensez-vous ? Cette technologie a-t-elle de l'avenir ?

Lire aussi :

:fleche: NVIDIA met le GPU Computing à la disposition des développeurs qui utilisent Visual Studio, avec Parallel Nsight

:fleche: CouchDB : la base de données NoSql arrive sur Windows, ce projet open-source serait plus rapide et plus simple que les SGBD classiques

:fleche: Apache Cassandra en version 0.6.0 est disponible : gain de performances de 30% pour la base de données NoSQL

Voir aussi

:fleche: Le forum GPGPU sur Developpez.com
:fleche: Une introduction à CUDA, un tutoriel de Thibaut Cuvelier

En collaboration avec Gordon Fowler
02/09/2010, 15h33
Traroth2

C'est une idée fantastique ! Les GPU semblent vraiment très adaptés aux opérations relationnelles, effectivement, en particulier les tris (parcours d'index, comparaisons) : un grand nombre d'opérations identiques très simples.

Mais par contre, il vaudrait mieux s'appuyer sur OpenCL que sur CUDA. Autant utiliser des standards ouverts...
02/09/2010, 16h05
djanggawul

La volumétrie traitée à l'air conséquente, mais il manque une valeur référence sans utilisation d'un GPU. Parce qu'un milliard d'entier ne signifie pas grand chose pour moi. Par contre, si on m'avait parlé d'amélioration des performances d'environ 50%, là ça me parlerait plus.
02/09/2010, 16h09
Desboys

Bonjour,

Va-t-on devoir penser à inclure des GPUs surpuissants/énergivore en SLI/CrossFire/etc lorsqu'on dimensionnera des serveurs de base de données?

Le retour du "co-processeur arithmétique" ? :P

Sébastien
02/09/2010, 17h21
Traroth2

Citation:

Envoyé par Desboys

Bonjour,

Va-t-on devoir penser à inclure des GPUs surpuissants/énergivore en SLI/CrossFire/etc lorsqu'on dimensionnera des serveurs de base de données?

Le retour du "co-processeur arithmétique" ? :P

Sébastien

En fait, je pense que cette idée a pour effet, entre autres de faire chuter la consommation électrique par transaction. On est en plein "Green IT", là !

Et à terme, peut-être que ça finira comme pour les coprocesseurs arithmétiques, par une intégration avec le CPU...
02/09/2010, 17h51
Kernald

L'intégration avec le CPU, c'est déjà en cours avec les IGP… Le passé se répète mais pas dans le même ordre ;)
02/09/2010, 18h52
mimix

J'espère qu'ils penseront à se diriger vers L'OpenCL, ils pourraient comme cela inclure un plus grand nombre de matériels.

Avec un serveur Tesla, ça devrait être pas mal au niveau performance.
A voir ce que ça donne au fur et à mesure du développement de leur projet.
02/09/2010, 19h07
pcaboche

La démarche est très intéressante.

Pour comprendre l'impact que cela aurait, il faut prendre en compte les autres facteurs limitants pour un SGBD, comme :
- les temps d'accès aux données (liés à la vitesse des disques durs)
- la quantité de mémoire (on ne peut pas tout mettre en cache, donc on est obligé de lire les données depuis le disque dur)

Trier 1 milliard d'entiers en 1 seconde, c'est très bien. Maintenant imaginons que l'on généralise cela pour trier des index.

Sur un cas réel, on arrivera peut-être à trier 1 milliard d'index en 1 seconde mais (les temps sont donnés à titre d'exemple) :
- on aura mis 10 secondes pour charger les index en mémoire
- à partir des index triés, on mettra encore 30 secondes pour lire les enregistrements correspondant sur le disque dur

La bonne nouvelle, c'est qu'on aura mis 1 seconde à trier 1 milliard d'index au lieu de plusieurs minutes avec un CPU. C'est non négligeable.

Sur le plan écologique, c'est aussi très bien. Au lieu d'avoir un CPU qui tourne à 100% pendant plusieurs minutes, on a un GPU qui fait le même calcul en 1 seconde. Le reste du temps (les accès I/O), le GPU ne consomme que très peu d'énergie.

Le gain offert par le GPU est donc très intéressant, ne reste plus que le temps d'accès I/O.

Puisque le facteur limitant est le temps d'accès aux données, idéalement ce qu'il faudrait faire c'est:
- lire les données sur le disque pour les mettre en mémoire
- appliquer simultanément sur les données en mémoire toutes les requêtes qui s'y rapportent

Mais dans la réalité, il est rare que plusieurs connexions aient besoin d'accéder EXACTEMENT aux mêmes données en même temps, donc cela n'aurait que très peu d'impact sur les performances.

Voilà, cela devrait donner une idée de l'impact que cela pourrait avoir sur les temps d'exécution des requêtes.

Citation:

Envoyé par djanggawul

La volumétrie traitée à l'air conséquente, mais il manque une valeur référence sans utilisation d'un GPU. Parce qu'un milliard d'entier ne signifie pas grand chose pour moi. Par contre, si on m'avait parlé d'amélioration des performances d'environ 50%, là ça me parlerait plus.

Avec l'exemple que j'ai donné plus haut cela devrait plus vous parler : le temps lié au tri des index devient négligeable, ne reste plus que les temps d'accès I/O.

Citation:

Envoyé par Traroth2

Mais par contre, il vaudrait mieux s'appuyer sur OpenCL que sur CUDA. Autant utiliser des standards ouverts...

OpenCL est très bien car, contrairement à CUDA, il n'est pas limité à un seul constructeur de cartes (nVidia) et ATI/AMD fait de très bonnes cartes.

Par contre, OpenCL est plus difficile d'accès et la documentation n'est pas toujours très claire. Donc on peut comprendre le choix pour CUDA.
06/09/2010, 17h44
dourouc05

Citation:

Envoyé par pcaboche

Le gain offert par le GPU est donc très intéressant, ne reste plus que le temps d'accès I/O.

Les cartes actuelles sont équipées d'un gigaoctet de mémoire, c'est-à-dire une quantité assez importante. Et ça, pour des cartes grand public. Maintenant, prenons une carte prévue pour du GPGPU : des NVIDIA Tesla, par exemple (ne jurant que par NVIDIA, mon choix n'est sûrement pas des plus objectifs). http://www.nvidia.com/object/product..._C2070_us.html, qui disposent de 3 ou 6 GB par carte ! L'autre modèle de Tesla http://www.nvidia.com/object/product..._c1060_us.html dispose de 4 Go. Dit autrement, il suffit de mettre toutes tes données sur ta mémoire sur le GPU, qui va à plusieurs gigaoctets seconde, donc bien plus rapide que ton disque dur. Pour une bonne partie des besoins, tu pourras charger entre tous les index et toute la base sur une seule carte. Pour des vrais besoins dans le domaine, avec des bases bien plus conséquentes, on va passer à des racks de Tesla : http://www.nvidia.com/object/product...-S2050-us.html, 1U, 4 cartes, 12 Go. On n'est pas si loin de serveurs actuels (bon, certains montent bien plus haut que ça).

Ensuite, cette technologie n'en est qu'à ses débuts : à quand de vrais clusters de GPU, des armoires des Tesla sur des mètres et des mètres ? On devrait avoir assez de place en mémoire pour mettre toutes les bases de données... si on a les fonds nécessaires. Là, plus de temps d'accès ou presque.
06/09/2010, 19h19
pcaboche

Citation:

Envoyé par dourouc05

Les cartes actuelles sont équipées d'un gigaoctet de mémoire, c'est-à-dire une quantité assez importante.

1 Go de mémoire, cela reste "peu" pour pas mal de serveurs de base de données en entreprise.

Mais comme tu le précises très justement, il s'agit là de cartes destinées au grand public; et les cartes professionnelles (comme les Tesla) peuvent embarquer plusieurs Go de mémoire.

Cependant tu ne pourras pas complètement supprimer les I/O. À un moment il faudra bien écrire les données sur le disque dur (même si cette opération peut être effectuée par le CPU pendant que le GPU s'occupe de tous les calculs en parallèle).

Et puis tu as aussi d'autres problèmes qui peuvent bloquer même la plus rapide des bases de données: des problèmes de transactions qui entraînent des deadlocks, par exemple.

Et puis il faut aussi laisser un peu de place pour la mémoire de travail, et donc enlever des données du cache.

Mais bon, c'est vrai qu'avec 4 cartes graphiques professionnelles ayant 6 Go chacune, il y a déjà de quoi faire... :aie:

Et c'est vrai que vu la rapidité d'exécution, ça diminue le risque d'avoir de longues transactions qui rentrent en concurrence. :aie: (quoique...)

Par contre, si tu arrives à mettre toutes tes données en mémoire, est-ce que cela ne fera pas apparaître d'autres problèmes, notamment des problèmes de latence si un thread a besoin d'une donnée qui n'est pas dans la mémoire partagée ? (je te demande cela car, bien qu'ayant lu ton excellent article sur les bases de CUDA, je n'ai pas tout compris quant à l'utilisation de la mémoire en GPGPU)
09/09/2010, 16h49
the_babou

je vais faire noob, mais comme cela a déjà été dit, pour faire des comparaisons objectives, il faut une référence: le même programme sur CPU classique.

d' où ma question: il faut combien de temps à un CPU standard (genre un core i5/i7 ou phenom II) pour faire le même calcul ?

parce que c' est peut être juste aussi performant de prendre un serveur avec plusieurs cpus, non ?
09/09/2010, 17h03
stardeath

je ne suis très convaincu pour l'instant, les données sur les disques durs, il faut déjà les charger en mémoire vive, puis en mémoire vidéo, déjà ça fait pas mal de transfert rien que pour l'aller.

ensuite (et là je ne connais pas cuda, j'extrapole à partir de mes connaissances en direct compute, normalement à peu près similaire dans les concepts) si on a besoin de trier 1 Go de données, il faut en en tout 2 Go pour le faire, vu qu'on ne peut pas faire d'écriture en place, ça limite encore les données qu'on peut traiter simultanément.
10/09/2010, 12h21
pcaboche

Citation:

Envoyé par the_babou

d' où ma question: il faut combien de temps à un CPU standard (genre un core i5/i7 ou phenom II) pour faire le même calcul ?

Si les calculs sont parallélisables, il n'est pas rare que les calculs soient plus de 100x plus rapides sur GPU que sur CPU.

À titre d'exemple, une GeForce GTX 285 comporte 240 shaders unifiés, qui peuvent être utilisés pour faire du calcul parallèle (mais reconnaissent moins d'instructions qu'un coeur de CPU).

Citation:

Envoyé par the_babou

parce que c' est peut être juste aussi performant de prendre un serveur avec plusieurs cpus, non ?

Non.

Non seulement les CPU contiennent beaucoup moins de coeurs que les GPU ne contiennent de shaders, mais en plus la bande passante entre plusieurs CPU est beaucoup moins élevée qu'au sein d'une carte graphique.

Citation:

Envoyé par stardeath

je ne suis très convaincu pour l'instant, les données sur les disques durs, il faut déjà les charger en mémoire vive, puis en mémoire vidéo, déjà ça fait pas mal de transfert rien que pour l'aller.

Oui, ce qui coute cher en temps, ce sont les transferts de données entre la RAM et la mémoire de la carte graphique (plusieurs centaines de cycles pendant lesquels le GPU ne fait rien).

C'est pour cela qu'on se demandait dans quelle mesure il était possible de mettre des données en cache sur la carte graphique.

Citation:

Envoyé par stardeath

si on a besoin de trier 1 Go de données, il faut en en tout 2 Go pour le faire, vu qu'on ne peut pas faire d'écriture en place, ça limite encore les données qu'on peut traiter simultanément.

Un thread GPU peut lire et écrire dans le même espace de données, mais il faut faire attention aux problèmes de synchro concernant l'accès aux données.

En effet, il ne faut pas que plusieurs threads écrivent en même temps dans le même espace de données, sans quoi les données seront faussées. De même, il ne faut pas qu'un thread lise une données qui puisse être modifiée par une autre thread.

Donc si l'algorithme de tri est "sur-place" et que chaque thread trie un ensemble de données sans déborder sur le voisin, il n'a a pas de problème.
10/09/2010, 13h06
stardeath

Citation:

Envoyé par pcaboche

Un thread GPU peut lire et écrire dans le même espace de données, mais il faut faire attention aux problèmes de synchro concernant l'accès aux données.

En effet, il ne faut pas que plusieurs threads écrivent en même temps dans le même espace de données, sans quoi les données seront faussées. De même, il ne faut pas qu'un thread lise une données qui puisse être modifiée par une autre thread.

Donc si l'algorithme de tri est "sur-place" et que chaque thread trie un ensemble de données sans déborder sur le voisin, il n'a a pas de problème.

ha bah cool, vivement que ça devienne pareil partout.
14/09/2010, 23h04
iberserk

6 giga sont suffisant pour une base dite 'moyenne' (10/20 giga)
Certaines base atteignent le tera...'a fortiori quand elles sont mal modélisées (ce qui est courant) difficile de tout mettre en mémoire...