Re: x86 ou pas ?

Je connais ce test et aussi un commentaire qui le contredit :

L'analyse de ce site sur les performances inferieures d'osx sur MySQL sont completements tirees de nul part, bases sur des suppositions et une meconnaissance totale de comment est construit osx.

Ils parlent de l'implementation des threads sur os osx qui serait moins bonne que sur Linux, pour exploquer qu'osx pert beaucoup de temps a creer des threads lorsque MySQl le reclame. Pour cela ils font un test avec LMBench. Bien ils sont tous faux sur plusieurs choses:
- Sur le test LmBench, on voit que ce test permet d'observer les appels aux commandes fork() et exec() qui tous deux permettent la creation d'un nouveau process. Et c'est la ou ils ont tous fau, car il semble qu'ils ne savent pas faire la difference entre threads et process (je garde les termes anglais). MySQl est un process en lui meme, et lors de son execution ils crent des nouveux threads, pas de nouveau process. Sa veut dire que MySQl n'appele JAMAIS fork() lors de son execution, donc leur test LmBench ne nous dis absolument rien sur le soi disant probleme de thread sur osx, car ils mesures des choses totalement differentes. Sa veut dire quoi tous ca, c'est quoi les resultats qu'ils montrent?

- Ensuite ils sont sur qu'os X n'utilise pas des kernel threads pour implementer des threads creer dans l'espace utlisateur. C'est totalement faux, les threads utilisateurs sont mappes directement vers le kernel, je ne vois pas de quoi ils parlent lorsqu'ils parlent de "several threading wrappers". On peux voir dans le code source de Darwin que les threads sont bien directement mappes au niveau kernel:

/* Create the Mach thread for this thread */
PTHREAD_MACH_CALL(thread_create(mach_task_self(), &kernel_thread), kern_res);

- On peut voir la confirmation de ceci sur le blog d'un ingenieur d'apple qui semble vouloir repondre aux propos d'AnandTech. De plus il propose une expliquation sur les perfs inferieurs de MySQL sur osx, qui semblent du a un unique mecanisme de verification de l'integrite des donnees manipules par la base de donnee. L'expert en systeme de fichier chez apple Dominic Giampaolo explique plus precisement ce qui se passe et pourquoi ce genre de macanisme a ete implemente:
http://lists.apple.com/archives/darwin-dev...b/msg00072.html(...)
Il a egalement poste un commentaite sur le site de MySQL en bas de page:
http://dev.mysql.com/doc/mysql/en/news-4-1-9.html(...)

Donc les performances inferieures rencontres par MySQL semblent etre du (C'est encore a verifier et seulement un profiling de MySQL lors de son execution nous donnera confirmation, ce que ce site n'a pas fait. Pourquoi? J'e compte le faire, quand j'aurais installe MySQL) par ce mecanisme de protection des donnees (qui est relativement lent) et non par la theorie mal devinees de threads imaginees par ces types qui ne savent meme pas faire la difference entre un thread et un process. Leur description de l'architecture d'osx (comment Mach et BSD sont implementes pour former xnu) est bourre d'erreures d'incomprehension, et notament leurs commentaires sur les changement faits dans Tiger pour le support des couches reseaux et du systeme de fichier du mulltithreading (fine grained locking). Pour ceux que cela interesse je peux expliquer de quoi il s'agit, je fais parti de la communaute Darwin.

- Enfin leur test sur les performances FPU sont plus que criticables, car ils utilisent un test ecrit en 1992!!!! totalement inadapte pour tester les processeurs actuels que se soit x86 ou G5. Comment peuvent-ils penser que du code ecrit il y a 13 and peut etre significatif des performces FPU d'un tel ou tel cpu. C'est une blague......Pourquoi ne pas utiliser Linpack pour le test FPU purs.

Bref beaucoup d'incoherences dans cet article et de fautes relatifs a une mauvaise comprehension du system et du comment il fonctionne.

http://www.pcinpact.com/actu/news/G5_contre_x86_et_Mac_OSX_contre_L(...)

Mais personnellement je ne sais pas qui a tort ou raison vu que je n'y connais strictement rien en MySQL.