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.

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.

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