BFS: Výkonnostní testy na low-end hardwaru

Phoronix otestoval výkon nového plánovače BFS (autor Con Kolivas). Ačkoliv výsledky nejsou jednoznačné, zdá se, že BFS je přeci jen o něco výhodnější (s výjimkou zvýšení diskové latence) než CFS.

14.9.2009 13:26 | Robert Krátký | Zajímavý článek

Komentáře

[l4m4]

Phoronix otestoval MD5 součty ISO obrazů distribucí GNU/Linuxu. Zvítězilo OpenSUSE se skóre e29311f6f1bf1af907f9ef9f44b8328b, s poměrně velkým náskokem na Slackware (b026324c6904b2a9cb4b88d6d61c81d1), který už byl těsněji následován Fedorou na třetím místě (9ffbf43126e33be52cd2bf7e01d627f9) a Debianem (9ae0ea9e3c9c6e1b9b6252c8395efdc1). Rozdíl mezi těmito dvěma distribucemi je, jak sami vidíte, nepatrný. Ubuntu v tomto testu zcela propadlo, dosáhlo pouze hodnoty 1dcca23355272056f04fe8bf20edfce0, což je překvapivé, obzvláště uvážíme-li, že jeho minulá verze si vedla velmi dobře se skóre c30f7472766d25af1dc80b3ffc9a58c7.

[michich]

Takový test na Phoronixu by mě snad ani nepřekvapil

[Mti.]

moc hezke :)

[Mandarinka]

lol... to je špičkový :DDD

 

[jozefH]

... tak a je to jasne, mazem Ubuntu, instalujem OpenSUSE :)

[Milan Lajtoš]

Veľmi podarené!

[Mandarinka]

Zde je překlad pro potřeby zahraničního trollování :D

"Phoronix has tested the MD5 hashes of various GNU/Linux distributions’ ISO images. OpenSUSE ended up first with the result of e29311f6f1bf1af907f9ef9f44b8328b, showing a relatively big lead over the runner-up Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which was followed more closely by Fedora in the third place (9ffbf43126e33be52cd2bf7e01d627f9) and Debian in the fourth (9ae0ea9e3c9c6e1b9b6252c8395efdc1). As you can see, the difference between these two distributions is almost negligible. Ubuntu turned out to be a huge disappointment in this test, achieving just 1dcca23355272056f04fe8bf20edfce0, which is actually very surprising, considered that the previous version performed more than solidly with a score of c30f7472766d25af1dc80b3ffc9a58c7."

[2X4B-523P]

LOL

[Milan Lajtoš]

Celkom ma prekvapuje, že BFS ktorý je určený na zníženie latencie testujú vo výkonnostných testoch. Čo tak pustiť nejakú náročnejšiu úlohu (prehrávať HD video) a merať koľkokrát sa zasekne kurzor na obrazovke? ;)

[Mandarinka]

Hmm, to jo, ale kolik to zlepšení odezvy stojí je taky dobrý vědět (aby to třeba neznemožnilo to přehrávání HD videa). Imho by ale nebylo špatný mít tohle defaultně na desktopových distrech.

[werwer]

 O video  bych se nebál, třeba komprese 7zipem byla rychlejší o 7 %.  Ztrátou výkonu trpí jen rychlost diskových operací.

[Drew]

Coz je uplne jedno, protoze kdyz ted trva nejaka diskova operace hodinu, tak je hodinu pocitac spatne/ne pouzitelny, kdezto kdyz nejaka diskova operace s bfs trva hodinu a pul, tak je pocitac nepouzitelny 0 minut - tedy jestli je pravda, ze bfs tento problem resi, nezkousel jsem to, nechce se mi kompilovat kernel.

[stativ]

To už možná opravuje jádro 2.6.31. Sice už ho delší dobu používám, ale jaksi jsem za tu dobu neměl potřebu nějak výrazně přesouvat velké množství dat, takže nemám odzkoušeno, jestli ta oprava opravdu pomáhá.

[Grunt]

Ach jo. Nechci do toho furt kecat, už mi to přijde trapné, ale opravdu se vám kurzor kouše, když je 100% vytížený procesor? Hlavně když je ten kurzor už většinou HW(nemáte čirou náhodou zapnutý SW kurzor?). Není to čirou náhodou při I/O operacích, I/O wait a jiných speciálních příležitostech? Protože v mém případě se nekouše při 100% zatížení ani na 100HZ, zato při diskových operacích(či a hlavně spíš když je plná sběrnice) se dovede kousnout i u BFS.

[dfsdgfsd]

Notebook Celeron 600 MHz, 192 MB RAm , Gentoo. S jádrem 2.6.23 a běžící kompilací nepoužitelné, jak se to seká. S jádrem 2.6.31 BFS 209  při běžící kompilaci můžu normálně používat (surfovat atd).

[dfsdgfsd]

btw. desktop quadcore mi s BFS 211 ani nenabootuje, sekne se při USB jak něco kutí u čtečky karet. Včera jsem sosnul BFS 221, tak uvidím dnes odpoledne až se vrátím z práce.

[Max]

Nevím, jak u výkonných strojů, ale já testoval BFS na AthlonuXP 2000+. K testování jsem použil distribuční jádro ArchLinuxu 32bit 2.6.29 a 2.6.30. U obou měl FF problémy s přehrávaním flashe na youtube. Ze začátku se trochu cukaly apod. Pak jsem sosnul zdrojáky k 2.6.31, opatchoval na BFS, zkopíroval config z 2.6.30, zaškrtal několik modulů naívc, co 2.6.31 přinesla a po dvou hodinách kompilace jsem jádro otestoval a paráda, flash šlape jak, z praku, okna jsou svižnější atd. Teď ho chci jít testovat na něčem silnějším (opteron 144), tak uvidíme.
Zdar Max

[Mti.]

A zkousel's 2.6.31 bez BFS? Z toho co pises tak ne. leckde jsem zahlidl, ze .31 ma byt v tomto ohledu lepsi sama o sobe. (nemam vyzkouseno osobne)

[Max]

Bohužel,. v době psaní komentáře ještě není k dispozici v archu / stable a vzhledem k tomu, že se mi 2.6.31 s distribučním configem kompilovala přes dvě hodiny, tak jsem se nato vykašlal. Ale až přijde s aktualizací, tak schválně vyzkouším :)
Zdar Max

[Mandarinka]

Hmm, tak to vypadá, že má BFS pozoruhodně lepší výsledky při běhu x264, což je sice úloha náročná na cpu, ale nezdá se mi, že by byla na plánovač náročná... nepotřebuje to moc IO, jenom spoustu cpu cyklů...

marc.info/

[xm]

Četl jsem na fórech BOINC (distribuované výpočty jako třeba SETI@Home) nadšené příspěvky o BFS. Počítání jim s BFS prý trvá podstatně kratší dobu (nedaří se mi to teď zpětně najít, ale byly to rozdíly v řádu _hodin_). BFS jim totiž prý lépe vytíží stroje s více jádry (zatímco se standardním plánovačem neměli nikdy všechny jádra vytížené na 100%, s BFS tomu tak je - a přitom je zachována interaktivita systému). To je myslím si důvod, proč je rychlejší i enkódování x264.

[xm]

Btw. BFS je právě plánovač CPU, nikoliv plánovač IO. Nahrazuje jediný jaderný plánovač CFS.

Plánovačů IO je v jádře víc (cfq - ten je defaultní, anticipatory, deadline a noop) a dají se přepínat i za běhu pro jednotlivá bloková zařízení. Bohužel Linus odmítá mít i vícero CPU plánovačů (přestože už v minulosti lidé udělali patche umožňující jejich výběr - vždy byly odmítnuty).

[Mandarinka]

Jo, jasně. Ta zmínka o IO se vztahovala k tomu, co x264 dělá: prakticky nikdy nečeká na data z disku, protože je limitována výkonem cpu... na středních a pomalých nastaveních pak podle mě prakticky už nečeká ani na RAM... (ačkoliv, nedávno si vývojář posteskl, že jim v dosažení vyšších rychlostí brání cache missy u L1 :) že tam není moc vyřešený prefetching...)