IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

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

  1. #1
    Expert éminent sénior
    Avatar de Idelways
    Homme Profil pro
    Développeur Ruby on Rails / iOS
    Inscrit en
    Juin 2010
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : Juin 2010
    Messages : 1 374
    Points : 68 548
    Points
    68 548
    Par défaut 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.

    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

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    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...

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    37
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 37
    Points : 28
    Points
    28
    Par défaut
    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.

  4. #4
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2005
    Messages
    241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2005
    Messages : 241
    Points : 399
    Points
    399
    Par défaut
    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

  5. #5
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    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...

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    132
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 132
    Points : 89
    Points
    89
    Par défaut
    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

  7. #7
    Futur Membre du Club
    Profil pro
    Inscrit en
    Juin 2005
    Messages
    3
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : Juin 2005
    Messages : 3
    Points : 5
    Points
    5
    Par défaut
    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.

  8. #8
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    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.
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  9. #9
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 609
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 609
    Points : 188 582
    Points
    188 582
    Par défaut
    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.
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  10. #10
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    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)
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  11. #11
    Membre du Club
    Inscrit en
    Septembre 2009
    Messages
    20
    Détails du profil
    Informations forums :
    Inscription : Septembre 2009
    Messages : 20
    Points : 49
    Points
    49
    Par défaut
    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 ?

  12. #12
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    Par défaut
    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.

  13. #13
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par the_babou Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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.
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  14. #14
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 376
    Points : 4 928
    Points
    4 928
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    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.

  15. #15
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    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...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

Discussions similaires

  1. Créer des graphismes 2D lorsque l'on est programmeur : fissure dans les fenêtres de bureau
    Par LittleWhite dans le forum Développement 2D, 3D et Jeux
    Réponses: 0
    Dernier message: 22/10/2014, 20h55
  2. Réponses: 3
    Dernier message: 20/06/2007, 23h18
  3. Réponses: 1
    Dernier message: 13/04/2007, 00h47
  4. Réponses: 15
    Dernier message: 29/10/2006, 19h01
  5. Réponses: 3
    Dernier message: 20/09/2006, 23h35

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo