Srovnání výkonu FreeBSD, Linuxu a OpenSolarisu (diskuse)

[nikdos]

He... kdyby radsi srovnali vykon sitovyho stacku

[xm]

Zajímavé jsou testy okolo výkonu čtení a zápisů na disk. UFS je opravdu těžkým děditstvím minulosti, tak špatné výsledky se jen tak nevidí. FreeBSD by se ho mělo konečně zbavit.

[tomasgn]

nevim, proc soudruzi z phoronixu nepouzili na FreeBSD taky ZFS, pak by ta cast testu mohla byt zajimava.

[michich]

Hned na úvod mě pobavila formulace "FreeBSD 8.0 introduced support for a TTY layer rewrite, ..."

[Limoto]

ROFL

[Radek Hladik]

Už se těším na diskuzi. Poměrně často se u podobných témat stává: Pokud je test pro FreeBSD příznivý, tak je považován téměř za svatý. Pokud je tomu naopak, tak je shazován, psali ho linuxáci nebo by měl měřit něco jiného. A to bez ohledu na to, že se jedná o test, který je zaměřen na oblast, která objektivně není hlavní cílová skupina FreeBSD... Let the flame begin

[Heron]

Je tam pár zajímavých věcí. Třeba výkon SSL mě překvapil dost.

Ten test s těmi náhodnými zápisy je velmi divný až vadný. Pokud jsou jednotky správně (us), tak ani jeden OS to nemohl stihnou zapsat do RAM natož pak na disk. 2GiB za 9us, to máme nějakých 200GiB/s. Takhle rychlé paměti bych tedy chtěl vidět.

[Heron]

Tedy spíše 200TiB/s

[Radek Hladik]

Přiznám se, že jsem test ještě nedočetl. Mluvil jsem obecně o testech, kde se vyskytne FreeBSD a Linux Objektivní výsledek testu je většinou poměrně irelevatni.

[Radim Kolář]

freebsd ma default pomerne nepriznive kompilacni volby pro benchmarky: -O2 -fno-strict-aliasing , chce to alespon optimalizaci na i686 a -fomit-frame-pointer. Pak jsou vysledky kernelu o 15%-20% lepsi.

Mne by zajimal test, kde by bylo freebsd i linux prelozeno stejnym kompilatorem se stejnyma optionama. Oddelil bych benchmark kompilatoru od benchmarku OS. Pak by byl test zajimavy, tohle je o nicem.

[Radek Hladik]

S druhou částí naplno souhlasím. Upřímně rečeno většina takovýchto testů je tak trochu o ničem. Pro mě je podstatné, jak snadno se systém nainstaluje, jak se spravuje a pod. A většinou výkon je až na dalších příčkách, samozřejmě v rozumných mezích. Potencionálích 10-15% výkonu klidně obětuju za jednodušší správu, rychlejší instalaci a pod. Například mojí oblíbenou Fedoru nainstaluju poměrně rychle, snadno nastavím a hotovo. FreeBSD po instalaci vyžaduje výrazně víc práce. Možná pak ve finále dostanu vyšší výkon, ale dokud ten rozdíl není nijak ohromný, tak mi za to nestojí.

[Heron]

Tak ono je také otázné, kam daná distribuce míří. Na serveru požaduji vysokou stabilitu a bezpečnost a je mi jaksi jedno, jestli to má o 20% pomalejší IO, když to tam stejně tak rychle po síti nedostanu. U Fedoru 12 na notebooku zase ocením výdrž na baterie a schopnost přehrát 1080p, což mě naopak na serveru vůbec neoslovuje. Stejně tak instalace, serverové distro si tak jako tak vyladím, což stojí nějaký čas, ovšem vydělený 6roky běhu. Na NTB chci mít každý půl rok nej distro ale věnovat tomu max půl hoďky.

Dá se to zhrnout i do jedné věty, tyhle testy jsou opravdu o ničem

[Miloslav Ponkrác]

Já osobně už nevěřím žádnému testu. Od té doby, co stále vychází v testech javistům opakovaně vychází, že Java je rychlejší, než C vím, že zálěží kdo chce jaký výsledek vidět.

Věci si testuji sám a často se nestačím divit jak odlišné výsledky často dostávám. Podmínky a šikovnost nastavení totiž dělá s výsledkem větší divy, než si lidé myslí. Případně mám pár známých, o kterých vím, že jsou schopni věci testovat tak, že se do toho nepromítá fandovství, či absolutně levé ruce (to se promítá do většiny testů), či neschopnost věc nastavit. Od takových pak přebírám zkušenosti, pokud se podělí.

[Murry]

Pod to se podepisuji.

[Karolinus]

ale to bejvá skoro ve všech testech, ... záleží na úhlu pohledu.

[l4m4]

Souhlas. Pravidelně porovnáváme výkon procesorů Intel a AMD pro naše numerické výpočty. Což znamená, že testujeme výkon na kódu zkompilovaném pokud možno optimálně pro daný procesor. A pokaždé nechápeme, kde se berou ty typické výsledky benchmarků, které člověk vidí publikovány. Nejspíš to testují na kódu pro i386 (který na Intelech běží excelentně, zřejmě kvůli windowsářům a právě těm benchmarkům). Jsou lži, špinavé lži a benchmarky...

[trekker.dk]

Nedávno jsem na třech strojích ukončil počítání Einstein@BOINC. Z nějakého důvodu se stejné úlohy procesorech od AMD počítaly třikrát déle než na výkonově srovnatelných procesorech od Intelu. Na to jim kašlu, když neumí udělat program tak, aby běžel všude dobře, nehodlám na ně plýtvat výkonem.

[xm]

Nebylo to třeba zkompilováno intelím ICC, který úmyslně zpomaloval kód na AMD procesorech? Netuším jestli s tou zrůdností už Intel přestal (když po nich šla Evropská Komise, i když tedy kvůli něčemu jinému), ale v minulosti tomu tak každopádně bylo.

[trekker.dk]

Intelí ICC mě napadlo taky, ale nepřišel jsem na to, jak zjistit, čím se to překládalo.

[x]

Vidim, ze i tady se strhla debata o tom, jak to FreeBSD projelo nebo jak jsou benchmarky obecne na nic (s cimz plne souhlasim). Ale to nejvice podstatne uteklo uplne vsem a i tvurci zpravicky. Linux je zde od roku 1991. OpenSolaris ve forme oficialniho vydani teprve cca 1.5 roku a podivejte se jak bud vyhral nebo drzel krok v mnoha tech testech s Linuxem. Vzhledem k tomu, ze testy Phoronix jsou obecne psany specificky pro Linux, tak se mi do mysli vkrada myslenka kde delaji lide z GNU/GPL chybu Z tohohle pohledu je ten vysledek pri porovnani s OpenSolaris jednoznacne ostuda.

[AHAHA]

Ano, delejme jako ze OpenSolaris byl napsan "from scratch". Vezmu Linux, vydam ho jako OpenLinux a to teprv budete cubrnet jak rychly dokaze byt hodinu stary OS!

[Sešívaný]

To bylo trefné

[x]

Ehm tak kazdy kdo se trochu orientuje, tak vi, ze OpenSolaris vychazi ze Solaris a to je v podstate ciste serverovy system. Multimedia atp. jsou tam dost ostuda a ty benchmarky Phoronix jsou vicemene desktopove. Desktop je to kde se Linux uz 18 let snazi porazit. Takze i kdyby se Linux prejmenoval na OpenLinux, tak mu to v tomto pripade vubec nepomuze

[AHAHA]

Rict o Linuxu, ze se zameruje hlavne na desktop je IMHO blbost ... minimalne, co se tyce vanilla kernelu.

[anti]

Tyhlety testy každého jenom otravují, já bych ty benchmarky zakázala...

[m;)]

"Instead of trying to compare something, I propose to look on that numbers itself first: - first test tells that average write latency is about 100us. But it looks quite surprising for Laptop HDD, which has seek time of at least several milliseconds. - second test - a bit closer to life - 2-3ms - ok, Linux won here slightly, as FreeBSD installation in this test had no NCQ support. - third test - 9us per write on Linux. I am just crying. - forth test - all OSes gave 50-80us. Probably it is just a buffer case read time.

So most of shown cases are testing almost only file system cache parameters. It is just insane to compare them for so different systems with so different write-back policies.

If somebody still have questions, after some UFS parameters tuning I've got with the same tiotest tool: - Random Write latency - 15us, - Random Read latency - 7us.

So who can beat my FreeBSD? :)))

What's about second test. To check possible NCQ effect I've built test setup with new 320GB 7200RPM Seagate drive connected to Intel ICH10R controller. I've run IMHO more reasonable benchmark/raidtest tool from ports on whole device, to execute pregenerated random mix of 10000 random-sized (512B - 128KB) read/write requests using default ata(4) driver and new ahci(4): Number of READ requests: 5029. Number of WRITE requests: 4971. Number of bytes to transmit: 655986688. Number of processes: 32.

The results: ata(4) - no NCQ: Bytes per second: 12455402 Requests per second: 189 ahci(4) - with NCQ: Bytes per second: 19889778 Requests per second: 303

Results are repeatable up to the 4-th digit. Average time per request is 5.29ms and 3.3ms respectively, that is realistic for this drive.

So, with such difference, I believe, we will not loose this test any more.

-- Alexander Motin"