> Moi non plus je ne vais pas y passer des plombes.
> TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Sous RH et FC il y a nptl *ET* linuxthread. L'appli qui veut linuxthread doit être linké à /lib/i686 (ou autre) mais pas à /lib/tls/libpthread.so. MySQL fait de lui même le choix d'utiliser nptl s'il est présent.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier) et donc ont peut avoir un code fait pour linuxthread qui marche avec nptl. C'est ce qui se passe avec *plein* *plein* *plein* d'applis et aussi avec mysql.
Je répète, mysql est codé ala linuxthread mais utilise nptl.
> Pour X<23 MySQL 4.0.X ne compilera même pas.
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
> Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Moi aussi (et ./configure n'utilise pas "--with-pthread"). Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
> Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Le bench, même s'il ne donne pas de raison, montre que Mysql est plus lent avec l'implémentation native qu'avec linuxthread. Point final.
Maintenant soit tu remets en cause l'intégrité du test en refaisant les tests, soit tu considères que MySQL est mal codé lorsqu'il utilise l'implémentation native, soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
> Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
Et alors ?
C'est toi qui dit que le problême est autour des mutex. Moi, je n'en sais rien. Je constate seulement que c'est plus rapide avec linuxthread.
[^] # Re: Désolé pour les trolls
Posté par fabb . En réponse au journal La guerre des OS. Évalué à 1.
> TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Sous RH et FC il y a nptl *ET* linuxthread. L'appli qui veut linuxthread doit être linké à /lib/i686 (ou autre) mais pas à /lib/tls/libpthread.so. MySQL fait de lui même le choix d'utiliser nptl s'il est présent.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier) et donc ont peut avoir un code fait pour linuxthread qui marche avec nptl. C'est ce qui se passe avec *plein* *plein* *plein* d'applis et aussi avec mysql.
Je répète, mysql est codé ala linuxthread mais utilise nptl.
> Pour X<23 MySQL 4.0.X ne compilera même pas.
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
> Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Moi aussi (et ./configure n'utilise pas "--with-pthread"). Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
> Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Le bench, même s'il ne donne pas de raison, montre que Mysql est plus lent avec l'implémentation native qu'avec linuxthread. Point final.
Maintenant soit tu remets en cause l'intégrité du test en refaisant les tests, soit tu considères que MySQL est mal codé lorsqu'il utilise l'implémentation native, soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
> Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
Et alors ?
C'est toi qui dit que le problême est autour des mutex. Moi, je n'en sais rien. Je constate seulement que c'est plus rapide avec linuxthread.