Hloubkové zkoumání výkonu PowerPC G5 a Mac OS X

15. 06. 2005, 19:51 · Nakousnutá jabka · Bleskovka

ikonkaNa Anandtechu vyšla recenze, která postupně popisuje procesor G5, jeho využití v pracovní stanici a serveru a také se zaměřuje na základy systému a práci s vlákny. Výsledek testu je poměrně nepříznivý pro Mac OS X – jako serverový systém například pro MySQL nebo Apache se podle názoru recenzenta nehodí, neboť systému trvá vytvoření všech vláken několikrát pomaleji než Linuxu, a výkon serverových aplikací jde při větší zátěži prudce dolů. Procesor G5 si také schytal pár připomínek, například za dost pomalý přístup k paměti. Výsledek je takový, že G5 je poměrně konkurenceschopný procesor pro pracovní stanice, pokud je aplikovaná kvalitní optimalizace pro Altivec, na serveru ovšem díky úzkému hrdlu v podobě základů Mac OS X byl Apple ošklivě pobit. Snad Apple zapracuje i v této oblasti…

· Trvalý odkaz na tento příspěvěk · Linkuj.cz · Jagg.cz

  1. Jestli je to pravda, tak na stejnem HW bude o dost pomalejsi… :-/

    — Lukas Kalista    15.6.2005 21:50    #

  2. 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.)

    Adam Nohejl    16.6.2005 01:16    #

  3. 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

    “jsou lzi, vetsi lzi a benchmarky”

    — gluon    16.6.2005 01:21    #

  4. a BTW zcela nechapu jak rychlost vytvareni prazdenych threadu souvisi s obslouzenim klientu

    — gluon    16.6.2005 01:22    #

  5. 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.

    Martin Lér    16.6.2005 02:29    #

  6. 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.

    — zzen    16.6.2005 03:41    #

  7. ad [6] . Co je mi znamo , tak MySQL ``neforkuje’’ , ale pouziva vlakna .

    — Honza Dušák    16.6.2005 09:39    #

  8. 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.

    Václav Dort    16.6.2005 10:19    #

  9. 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 )

    — Honza Dušák    16.6.2005 10:45    #

Související články