et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
MySQL le fait( faisait) avec les mutexs pour des raisons de rapidité d'éxecution.
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
Sur toutes les distribution en 2.6 aussi d'ailleurs. mais rien n'empèche de réclamer spécifiquement les LinuxThreads.
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Sur les fonctions posix standards oui, sur les autres non. Toutes les initialisation de Mutex en code finnissant par _NP dans LinuxThreads ne sont pas compatibles avec NPTL.
De plus les linuxthreads créent des threads avec chacun leur PID (chaque thread apparait comme un proces), NPTL n'a pas ce défaut.
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
J'ai dit que l'ensemble des MYSQL 4.x "vanilla" nécessitaient LinuxThreads pour tourner correctement. Apparament depuis la 4.1.8 ce n'est plus le cas. Cependant la 4.0.22 (utilisé dans le test) requiert absolument les Linuxthreads (0.71+). Apparament ce n'est plus le cas pour la 4.0.23 (Test fait sur ma gentoo, noyeau 2.6.9) mais la stabilité n'est pas au rendez-vous. Le manuel d'installation de la 4.0.23 précise d'ailleurs qu'il faut utiliser LinuxThreads cf http://dev.mysql.com/doc/mysql/en/source-notes-linux.html(...) MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
A noter que ceci prouve que
a) NTPL n'est pas 100% retro compatible avec LinuxThreads (4.022 ne passe pas, 4.023 est instable)
b) Les libs linuxthreads sont bien linkées spécifiquement (MySQL 4.0.23 vanilla utilise préférentiellement LinuxThreads)
Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Pour les locks et unlocks de mutexs (ce qui nous interesse ici) c'est LinuxThreads en mode Mutex rapide qui est le plus rapide. Même si NPTL ets globalement plus performante, il existe encor eun poitn ou deux ou LinuxThreads est plus rapide.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
C'est pas sous-entendu. C'est affirmé, ave cdémonstration à l'appui. Et il n'y a pas de guillemets autour de honteusement non plus.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native)
Ah bon ? Chez moi c'est installé de base et c'est une option à passer à la compil. Mais bon.
Mais pour en revenir à ta remarque très juste, le testeur démontre avec brio que MySQL->NativeBSD threading est beaucoup plus lent que MySQL->LinuxThreads->Linux-To-PosixMapping->PosixThreads->Native BSD Threading.
Oui parcequ'au final sous BSD, ce sont quand même des threads BSD qui vont être créés.
La première idée qui vient quand on obtient ce genre de résultats est "tiens ils ont codés les threads natifs BSD avec les pieds", celle qui ne devrait jamais venir est "Mon Dieu LinuxThreads et tellement bien que quand on l'utilise en surcouche de surcouche de surcouche de BSD Threadings on gagne des perfs par rapport au natif".
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 3.
MySQL le fait( faisait) avec les mutexs pour des raisons de rapidité d'éxecution.
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
Sur toutes les distribution en 2.6 aussi d'ailleurs. mais rien n'empèche de réclamer spécifiquement les LinuxThreads.
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Sur les fonctions posix standards oui, sur les autres non. Toutes les initialisation de Mutex en code finnissant par _NP dans LinuxThreads ne sont pas compatibles avec NPTL.
De plus les linuxthreads créent des threads avec chacun leur PID (chaque thread apparait comme un proces), NPTL n'a pas ce défaut.
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
J'ai dit que l'ensemble des MYSQL 4.x "vanilla" nécessitaient LinuxThreads pour tourner correctement. Apparament depuis la 4.1.8 ce n'est plus le cas. Cependant la 4.0.22 (utilisé dans le test) requiert absolument les Linuxthreads (0.71+). Apparament ce n'est plus le cas pour la 4.0.23 (Test fait sur ma gentoo, noyeau 2.6.9) mais la stabilité n'est pas au rendez-vous. Le manuel d'installation de la 4.0.23 précise d'ailleurs qu'il faut utiliser LinuxThreads cf
http://dev.mysql.com/doc/mysql/en/source-notes-linux.html(...)
MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
A noter que ceci prouve que
a) NTPL n'est pas 100% retro compatible avec LinuxThreads (4.022 ne passe pas, 4.023 est instable)
b) Les libs linuxthreads sont bien linkées spécifiquement (MySQL 4.0.23 vanilla utilise préférentiellement LinuxThreads)
Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Pour les locks et unlocks de mutexs (ce qui nous interesse ici) c'est LinuxThreads en mode Mutex rapide qui est le plus rapide. Même si NPTL ets globalement plus performante, il existe encor eun poitn ou deux ou LinuxThreads est plus rapide.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
C'est pas sous-entendu. C'est affirmé, ave cdémonstration à l'appui. Et il n'y a pas de guillemets autour de honteusement non plus.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native)
Ah bon ? Chez moi c'est installé de base et c'est une option à passer à la compil. Mais bon.
Mais pour en revenir à ta remarque très juste, le testeur démontre avec brio que MySQL->NativeBSD threading est beaucoup plus lent que MySQL->LinuxThreads->Linux-To-PosixMapping->PosixThreads->Native BSD Threading.
Oui parcequ'au final sous BSD, ce sont quand même des threads BSD qui vont être créés.
La première idée qui vient quand on obtient ce genre de résultats est "tiens ils ont codés les threads natifs BSD avec les pieds", celle qui ne devrait jamais venir est "Mon Dieu LinuxThreads et tellement bien que quand on l'utilise en surcouche de surcouche de surcouche de BSD Threadings on gagne des perfs par rapport au natif".
Enfin bon moi je dis çà...