Názory k článku
Jádro 6.17 je v průměru asi o 37 % rychlejší než jádro 5.15

  • Článek je starý, nové názory již nelze přidávat.
  • 26. 8. 2025 7:27

    Adam Kalisz
    Stříbrný podporovatel

    Článek bohužel úplně neodpovídá na to, proč je najednou software na tom samém hardwaru rychlejší jen po změně jádra. Tím by se dalo potom říct, jestli to je něco, co by bylo vidět obecně nebo jen na tom AMD Milan. Stejně tak to neříká, do jaké míry by byla třeba rychlejší virtualizace, pokud je hypervizorem novější jádro.

    Zdá se, že třeba u nginxu novější jádra prostě použijí o něco víc elektřiny, ale výkon v benchmarku je skoro dvojnásobný, takže novější jádra jsou pořád efektivnější. Takže třeba skok z Debianu 12 na 13 by v tomto případě měl být poměrný no brainer, pokud na těch benchmarcích něco je.

  • 26. 8. 2025 10:46

    JMarek

    Proč ten despekt?

    Benchmarky z Phoronixu jsou skvělé, protože jednak tam jsou popsané naprosto přesně vstupní podmínky (v tomto případě nastavení pro jednotlivá jádra), jednak jsou tam i výsledky jednotlivých benchmarků a nakonec shrnutí.

    Je třeba se na to tedy podívat tak, jak ten benchmark vznikl: pro stejný HW a stejný SW měním jádro a zjišťuju, jak se mění výkon u jednotlivých benchmarků.

    Neřeší se, _proč_ se ten výkon mění. Řeší se, že se mění a jak. Což je ostatně cílem jakéhokoliv benchmarku, protože to je umělý test a ne reálný provoz. Jenže jen z výsledků umělého testu lze provést relevantní srovnání.

    Ostatně, na základě např. propadu výkonu jádra v testu na Phoronix-u se přišlo na několik regresí v jádře, takže to svůj smysl má.

    V tomto případě výkon stoupal, dokonce mi přijde, že se "ustálila" hodnota spotřeby, tj. spotřeba je "konzistentnější", má menší odchylky. Můj závěr z toho testu tedy je, že vývoj jádra jde správným směrem - k vyššímu výkonu, kupodivu i o trochu nižší spotřebě a větší konzistenci.

  • 26. 8. 2025 11:22

    Adam Kalisz
    Stříbrný podporovatel

    Ano, popsané to je poměrně detailně. Ale odborníkem se člověk nestane tak, že jen pozoruje, ale umí i spojit vzorce, správně interpretovat a vyvodit z toho odhady s vysokou mírou přesnosti.
    Třeba je docela rozdíl, jestli by člověk měl čekat výkonnostní zlepšení i pro starší procesory, nebo se to týká jen aktuálních kousků a navíc jen třeba od AMD.

    Pokud by šlo obecně říct, že do 3 let od uvedení nějakého procesoru velkých výrobců lze očekávat v řadě ohledů třeba 20-30% výkonnostní zlepšení díky optimalizacím, které se postupně dotáhnou, tak by se klidně mohlo stát, že to změní vzorce nakupování. Taky by bylo třeba zajímavé, kdyby tohle platilo pro AMD, ale neplatilo pro Intel. Věřím, že to by zase mohlo dost ovlivnit, na které procesory si pro další generaci infrastruktury provozovatel vsadí.

    Bohužel na žádné takové analýzy Phoronix neaspiruje a proto přináší jen zlomek hodnoty, co by přinášet mohl a proto Michael balancuje dlouhodobě na hranici vyhoření. Dělá hodně práce, ale podle všeho z toho není schopný vybudovat tým a všechno se odvíjí od toho, jak moc se on sám bude sdírat. Nenechává to prostor pro dovolenou, případné zdravotní komplikace, rodinné záležitosti, nenadálé události.

    Mám velký respekt k intenzivní práci a je fajn, když má někdo takový zápal pro věc jako Michael. Na druhou stranu ale vidím, že se trochu zahnal do kouta. Kromě nějakých příležitostných konzultací a s ohledem na investice, které musí pravidelně dělat je se současným přístupem v pozici, která nemá jasnou perspektivu. Bude to za 5-10 let fungovat pořád stejně? Je schopný udržet tempo, kdy 80-100 hodin týdně pracuje? Budou mu lidi ochotní za to platit +- stejně?
    Zkrátka po 20+ letech rubání by člověk u takto schopného člověka čekal, že bude mít vytvořenou takovou bázi, že i zkrácený pracovní týden pohodlně pokryje všechny potřeby a budování rezerv a zbytek času bude mít na rodinu, skutečná hobby, návštěvu Octoberfestu apod.

  • 26. 8. 2025 11:48

    Trident

    Vyvodit odhady muzete pokud mate pristup k interni dokumentaci cpu/cipu/mikro­kodu/tajnym technologiim -> coz nemate. A ani kdybyste mel nemuzete treba rici ze je to kvuli A a ne B protoze A i B jdou tajne uz jen nazvem. Takze maximalne muzete resit veci ktere o tom vyrobce rekne v oficialni ( ne prilis podrobne) dokumentaci pro devely a nezbyva vam nic jineho nez kvalifikovany velmi povrchni odhad na urovni: Diky nove architekture..., Jelikoz ma sirsi sbernici... atp.
    Jenomze uzivaka nezajima proc, ale ze to ma takovy vykon a za jakych uzivakovi snadno replikovatelnych podminek.
    Smirte se s tim. Je to dan za uzavrene technologie.

    26. 8. 2025, 11:48 editováno autorem komentáře

  • 26. 8. 2025 12:33

    Michal Kubeček

    Proč ten despekt? Benchmarky z Phoronixu jsou skvělé …

    Ne, vůbec nejsou skvělé, jsou naopak názorným příkladem, jak se to dělat nemá. On prostě jen vezme nějaké systémy, pustí na nich sadu benchmarků a publikuje výsledky. A pokud někde vidí výrazný rozdíl, opatří to barnumským titulkem.

    Jeden extrémní příklad, který mi utkvěl v paměti, byl ten, že spouštěl stejný síťový test (netperf nebo iperf) jako dva testy, přičemž ho jednou nechal běžet 10s a podruhé 60s (na ethernetu). Na první pohled je jasné, že pokud neuděláte nějakou zásadní chybu, musejí vám vyjít stejné výsledky v rámci minimální náhodné fluktuace. Jemu pro jeden testovaný systém vyšly diametrálně odlišné hodnoty a vůbec nezkoumal, co se stalo, nezkusil ten test zopakovat, prostě to tak publikoval a ještě prohlásil, že ten systém je v příslušném testu výrazně pomalejší.

    Jiný absurdní příklad byl "test rychlosti síťování v různých distribucích". To proběhlo tak, že nainstaloval pár distribucí defaultním postupem a s defaultní konfigurací a pak na nich pouštěl svou sadu benchmarků síťového provozu. Že některé distribuce defaultně spouštějí paketový filtr s connection trackingem, zatímco jiné nenastavují vůbec nic, to vůbec nepovažoval za problém, prostě prohásil, že ty první jsou mnohem pomalejší. Facepalm...

    A takhle by se dalo pokračovat velmi dlouho. Autor byl na tyhle problémy mnohokrát upozorněn, ale protože je mezi laiky (kterých je většina) ohromně populární, odmítá si připustit, že dělá nějakou chybu. Bohužel ho ale většina uživatelů, kteří necítí potřebu o věcech moc přemýšlet, pořád bere vážně.

    Je třeba se na to tedy podívat tak, jak ten benchmark vznikl: pro stejný HW a stejný SW měním jádro a zjišťuju, jak se mění výkon u jednotlivých benchmarků. Neřeší se, _proč_ se ten výkon mění. Řeší se, že se mění a jak.

    To je další příklad. Spustí se vybraná sada benchmarků na jednom konkrétním HW, koukne se na výsledek a prohlásí se Jádro 6.17 je v průměruo o 37% rychlejší, tečka. Neřeší se, jestli to stejně nebo aspoň podobně vyjde i za jiných okolností a jestli ten výsledek není specifický pro ten konkrétní sytém. Neřeší se, do jaké míry je to opravdu jádrem a do jaké míry změnami defaultů v jeho konfiguraci. Namátkou třeba různé hardening featury mohou s výsledky hodně zamíchat. Nebo CPU vulnerability mitigations, kde to navíc hodně závisí i na konkrétním procesoru.

    Jistě, udělat takové benchmarky pořádně, aby opravdu měly nějakou vypovídací hodnotu, by bylo mnohem víc práce. Ale přesně tohle Phoronixu vytýkám: zvolil jednodušší cestu a upřednostnil kvantitu nad kvalitou, takže hodnota jeho výsledků je krajně pochybná.

  • 26. 8. 2025 13:59

    Michal Šmucr
    Bronzový podporovatel

    Jistě, udělat takové benchmarky pořádně, aby opravdu měly nějakou vypovídací hodnotu, by bylo mnohem víc práce. Ale přesně tohle Phoronixu vytýkám: zvolil jednodušší cestu a upřednostnil kvantitu nad kvalitou, takže hodnota jeho výsledků je krajně pochybná.

    Ano přesně podobný pocit z toho mám taky. Upřímně se přiznám, že se ani zdaleka nevyznám ve všech oblastech a workloadech, které testuje. Možná konkrétně třeba různé verze jader se stejným nastavením při sestavování budou víc reprezentativní.
    Ale kolikrát třeba u filesystémů si říkám OMG, zvlášť když pak rozmlouvám s někým, co má ty zveřejněné výsledky za bernou minci.
    Takové ty okolnosti jako hot data, cold data nebo rychlé uložiště (NVMe - balls to the wall) vs pomalejší úložiště (s kontinuální alokací během flushování), situace při fragmentovaném volném místu. Paměťová náročnost, délky front při nějaké aplikační zátěži. Nebo běžné porovnávání CoW s normálními filesystémy bez dalšího nastavování na aplikační úrovni (třeba nastavení žurnálu, WaL u databází) atp.
    Přestože chápu, že nepíše přímo o tom, co si má kdo zvolit, tak občas trochu ponoru a nějakého kontextu okolo by podle mě rozhodně nezaškodilo.
    Podobně jako třeba nějaký základní instinkt technika, kdy pokud něco vychází v násobcích jinak než zbytek, tak to třeba třikrát zkontroluju, zkusím tomu přijít na kloub, zkontroluju podmínky a možná to ve výsledku i vyhodím z nějakého průměrování a napíšu proč.
    Chápu, že by pak těch benchmarků nebylo třeba 30 v jednom článku, ale měly by podle mě daleko větší hodnotu, přesně jak jste zmínil.

  • 26. 8. 2025 8:30

    Milenius

    Zajímal by mne podobný test s Windows :-)