IdentifiantMot de passe
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 !

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 , par Idelways
14 commentaires

16PARTAGES

1  0 
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.

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

Lire aussi :

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

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

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

Voir aussi

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

En collaboration avec Gordon Fowler
Vous avez lu gratuitement 5 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

14 commentaires
Commenter Signaler un problème
pcaboche
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 02/09/2010 à 19:07
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 Voir le message
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 Voir le message
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.
1  0 
Traroth2
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 02/09/2010 à 15:33
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...
0  0 
djanggawul
Avatar de djanggawul
Nouveau membre du Club https://www.developpez.com
Le 02/09/2010 à 16:05
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.
0  0 
Desboys
Avatar de Desboys
Membre averti https://www.developpez.com
Le 02/09/2010 à 16:09
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" ?

Sébastien
0  0 
Traroth2
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 02/09/2010 à 17:21
Citation Envoyé par Desboys Voir le message
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" ?

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...
0  0 
Kernald
Avatar de Kernald
Membre régulier https://www.developpez.com
Le 02/09/2010 à 17:51
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
0  0 
mimix
Avatar de mimix
Futur Membre du Club https://www.developpez.com
Le 02/09/2010 à 18:52
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.
0  0 
dourouc05
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 06/09/2010 à 17:44
Citation Envoyé par pcaboche Voir le message
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.
0  0 
pcaboche
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 06/09/2010 à 19:19
Citation Envoyé par dourouc05 Voir le message
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...

Et c'est vrai que vu la rapidité d'exécution, ça diminue le risque d'avoir de longues transactions qui rentrent en concurrence. (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)
0  0 
the_babou
Avatar de the_babou
Membre du Club https://www.developpez.com
Le 09/09/2010 à 16:49
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 ?
0  0 
Commenter Signaler un problème