Hm.. na tenhle clanek jsem slysel dost kritiky a potom, co jsem v nem skutecne nasel napriklad vetu: The Unix process/thread creation is called “forking” as a copy of the calling process is made. jsem se rozhodl ho radeji necist.
(Netvrdim, ze clanek je zcela mylny, ale jeho autori zjevne nemaji dostatecne vedomosti, takze bych radeji hledal informace jinde.)
za 1.) pry pouzili na anadtechu spatny compiler
za 2.) nepouzili apache2 ktery umi lip vyuzit SMP
za 3.) mohl byt problem s HDD buferovanim
atd.
na tehle adrese je test ktery tvrdi neco uplne jineho
http://www.pcmag.com/article2/0,1759,1637655,00.asp
diskuze na anadtech test
http://ridiculousfish.com/blog/?p=17
gluon: inu, pokud by to byl problem vylozene jen apache nebo utf8, tak to asi beru, ale snazili se tam to dokazat i pres nejake specialni microbenche? A co muze byt spatneho na gcc? mozna spatne nastaveni? Diskuse o flushovani a podobne jsou pro me prilis abstraktni, zvlast v tuto hodinu. Bohuzel vsichni o tom hlavne mluvi, idealni by bylo udelat nejake obdobne porovnani… (graf na PCMagu je hezky, ale chybi nejake porovnani)
Neboli, nechce se mi verit tomu, ze by to byl umysl (protoze problem se vyskytuje u dvou z nekolika ruznych softwaru, jinde to vychazi vyrovnaneji), je mozne ze maji chlapci zcela spatnou metodiku, je mozne ze se trefili do worst case scenario a je proste mozne ze maji pravdu, i kdyz tomu zcela nerozumeji (nebot tyto dva fakty se apriory nevylucuji).
Snad si nekdo da praci a brzo se objevi benchmarky, ktere budou vychazet zcela opacne.
Ty totálně pomalé výsledky MySQL už jsem viděl i jinde než na AndAndtechu a akceptuji je jako pravdivé. Začne to zpomalovat hlavně při vyšším zatížení.
rychlost forkování souvisí s obsluhou klientů v případě Apache prefork a i v případě MySQL dost výrazně! Stejně tak můžeš v gcc zapínat/vypínat některé druhy optimalizace, které mohou mít poměrně zásadní vliv na výsledek.
Možná, že ten menší výkon vytváření vláken souvisí u BSD s tím, že jsou imlementována do jádra, jak mají. Linux, pokud vím, dodnes tyto procesy nemá dokonale implementované do jádra a je to nějak ošizené. FreeBSD je na PC také pomalejší než Linux.
Podle http://developer.apple.com/technotes/tn/tn2028.html jsou vlakna v MasOXu postavena na Mach-ovskych vlaknech , takze implementace se lisi s FreeBSD .
Ve FreeBSD nedavno zmenili implementaci vlaken z user-space ( 4.x ) na kernel-space ( 5.x )
— Lukas Kalista 15.6.2005 21:50 #
(Netvrdim, ze clanek je zcela mylny, ale jeho autori zjevne nemaji dostatecne vedomosti, takze bych radeji hledal informace jinde.)
— Adam Nohejl 16.6.2005 01:16 #
za 2.) nepouzili apache2 ktery umi lip vyuzit SMP
za 3.) mohl byt problem s HDD buferovanim
atd.
na tehle adrese je test ktery tvrdi neco uplne jineho
http://www.pcmag.com/article2/0,1759,1637655,00.asp
diskuze na anadtech test
http://ridiculousfish.com/blog/?p=17
“jsou lzi, vetsi lzi a benchmarky”
— gluon 16.6.2005 01:21 #
— gluon 16.6.2005 01:22 #
Neboli, nechce se mi verit tomu, ze by to byl umysl (protoze problem se vyskytuje u dvou z nekolika ruznych softwaru, jinde to vychazi vyrovnaneji), je mozne ze maji chlapci zcela spatnou metodiku, je mozne ze se trefili do worst case scenario a je proste mozne ze maji pravdu, i kdyz tomu zcela nerozumeji (nebot tyto dva fakty se apriory nevylucuji).
Snad si nekdo da praci a brzo se objevi benchmarky, ktere budou vychazet zcela opacne.
— Martin Lér 16.6.2005 02:29 #
rychlost forkování souvisí s obsluhou klientů v případě Apache prefork a i v případě MySQL dost výrazně! Stejně tak můžeš v gcc zapínat/vypínat některé druhy optimalizace, které mohou mít poměrně zásadní vliv na výsledek.
— zzen 16.6.2005 03:41 #
— Honza Dušák 16.6.2005 09:39 #
— Václav Dort 16.6.2005 10:19 #
Ve FreeBSD nedavno zmenili implementaci vlaken z user-space ( 4.x ) na kernel-space ( 5.x )
— Honza Dušák 16.6.2005 10:45 #