Názory k článku Kolik stojí provoz Gentoo? Zruinují vás náklady na elektřinu?

Nie je to tak, že keď si software skompilujem "na mieru", tak ten potom môze bežať o niečo efektívnejšie? Keby sa to dalo nejako kvantifikovať, možno by to aj zahýbalo výsledkom rovnice.

Efekt se ti projevi, ale primarne na vecech, ktere vyrazne vytezuji HW. A typicky system je spis trvale v iddle. Pro me je gentoo primarne o tom, ze tam nemam hnuj knohoven, ktery nanic nepotrebuju, coz znamena mene problemu, vetsi bezpecnost atd atd.

Tohle se přeceňuje. Viděl jsem za dvacet let spoustu benchmarků a rozdíly jsou minimální nebo vůbec žádné. Nemá smysl si kompilovat Gentoo a očekávat, že výsledek bude zázračně o 20 % výkonnější.

Takový systém má smysl proto, abych si ho postavil podle svých požadavků a přidal třeba nějaké speciální vlastnosti, které mi už připravené zkompilované prostředí nenabízí.

Je to tak. Když jsem na Gentoo přecházel přibližně někdy před před dvaceti lety, tak se nárůst výkonů díky optimalizacím uváděl snad někde kolem 2%.

Když se podívám na PassMark, tak ten procesor má nějakých 4645 bodu.
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-2600S+%40+2.80GHz
Tohle ale není žádný přesný údaj. Je to průměr hodnot, které pošlou uživatelé, kteří si jejich software spustí na svém počítači. Když si to spustím já, tak naměřím 5156 bodu, tedy asi o 11% víc, než je průměr. Tady by ale bylo pořád moc jednoduché říct, že to je díky Gentoo. Většina lidí, co si ten test spustí, bude mít patrně Windows a jak nedávno proletělo internetem, tak Ubuntu 24.04 má přibližně o 20% vyšší výkon, než jaký je ve Windows.
https://www.root.cz/zpravicky/ubuntu-24-04-je-v-prumeru-o-20-rychlejsi-nez-windows-11/

To jsou tak malé výkyvy, že to je vlastně jedno. Spíš záleží na tom, co u toho člověk děla. Třeba taková Nova a jejich TN.CZ. To je peklo.
Nedávno jsem si trošku testoval úsporný počítač s Intel N100. 5556 bodu v PassMarku a TDP 6W. Na tomhle počítač stačí otevřít ve Firefoxu titulní stránku a celková spotřeba počítače vyskočila o 5W. Když stejný web otevřu já na své staré i7 2600S, tak spotřeba vyskočí o 15W. Stačí jeden blbě napsaný web a výkyvy jsou v desítkách procent.

Dnes sú v procesoroch veci typu out of order execution, branch prediction atď. Tie sú zdrojom nepekných bugov. Čo ak by takéto robil kompilátor a procesur by bol úplne deterministický?

Len som sa zasnil, trochu sa teraz hrám s Fortranom.

Pár takových experimentů jsem už zaregistroval. Nějak se to neujalo.

A ještě jedna věc. Když ten out of order execution není přímo v interface procesoru, tak ho může výrobce procesoru aspoň trochu překopat updatem mikrokódu. I když je to třeba za cenu dost drsného poklesu výkonu. Potřebuje k tomu jen spolupráci od OS.
Kdyby to dělal kompilátor, pak tuhle opravu výrobce udělat nemůže. Otevřelo by to možnosti pro chyby, které by nebyly opravitelné bez rekompilace úplně všeho opraveným překladačem. A že by autoři překladače nemohli nasekat podobné chyby jako autoři procesorů se mi moc nechce věřit :)

A snažit se číst výstup překladače třeba pro VLIW architekturu se softwarově zpipelinovanými instrukcemi vážně nechcete. ;) Ověřit výstup překladače, pokud generuje něco jako x86 assembler je proti tomu brnkačka.

25. 4. 2024, 12:34 editováno autorem komentáře

Dnes, keď kompilátory produkujú rôzne medzikódy a bajtkódy, by sa dalo už kadečo riešiť. VLIW možno len prišla priskoro, a ešte nie je jej čas, čo my vieme. Vo svete procesorov je to bežné, taký Apple by mohol rozprávať, tí kvôli projektu Aquarius stratili strašne veľa peňazí, pritom použili myšlienky bežné v dnešných procesoroch. Len boli moc napred a nespravili to dobre.

25. 4. 2024, 13:04 editováno autorem komentáře

Takhle fungoval Itanic, ale něco na tom debuggovat na úrovní instrukcí byl masakr. I obyčený delay slot na Sparcu zhoršuje přehlednost.

Povedzme, že by ste chceli debugovať na úrovni mikrokódu, tiež to bude masaker, nie?

Povedzme, si kúpim Ryzen. A poviem si "Tak, teď si tě zdebuguji". Môžem? Že by som napichol jtag do procesoru a nejak si ten mikrokód prekrokoval, alebo tak ...

Já se s tím potkal u DSPček od TI. Psát v tom assembler bylo takové peklo, že se assembler pro stroj překládal z assembleru pro lidi.

Mě vyléčil CachyOS. Zkusil jsem vychvalovanou optimalizaci CPU ale výsledek je zklamání. Nemá to prakticky smysl

Tak já provozuji Gentoo víc jak deset let a souhlasím se vším, co zaznělo v článku.

Dlužno pouze dodat, že Gentoo nově podporuje binární balíčky jako 1st class citizens:
- https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html
- https://wiki.gentoo.org/wiki/Binary_package_guide

Tohle je taky velmi zajímavé téma a taky na něj už chystáme podrobný článek.

A taky nutno dodat, že občas jsou binární balíčky nezbytnost.

Zachránily mi situaci např. když se mi na stroji s omezeným úložištěm nechtěl zkompilovat Rust. Ta potvora vyžaduje jestli si matně vzpomínám okolo 8 - 10GB (víc?) volného místa na disku během kompilace. Nezanedbatelně, pokud mám pro systém vyhrazeno třeba jen 64G a z toho velkou část zabírají jiné věci a ten Rust se tam postupem času, po letech provozu, vetřel s nějakou závislostí a nebylo s ním počítáno.

Nemluvě o tom, že kompilace trvá věčnost i na relativně moderních strojích (ale třeba cíleně omezených kvůli velikosti/teplo­tě/chlazení/spot­řebě takže tam je místo 20+ jader jen úsporné 4 jádro).

... netvrdím, že Gentoo byla nejlepší volba pro takovou situaci, ale roling update je roling update.

Ale rolling distra mate, napriklad Debian testing.

Ta hromada hnoje (rust) predevsim pro kompilaci vyzaduje, aby CPU umel instrukci, kterou 50% procesoru neumi (napriklad plati pro vsechny celerony). A dalsi krasna vlastnost toho hnoje je ta, ze to neumi zkompilovat ani samo sebe. Do systemu se to nacpe jen a proto, aby to zkompilovajo jednu naprosto zbytecnou a nepotrebnou pythoni knihovnu, ktera je tam proto, ze python pouziva gentoo jako scriptovac.

A jak pises, za cas kompilace tohoto hnoje se prekompiluje cely zbytek systemu.

> Ta hromada hnoje (rust) predevsim pro kompilaci vyzaduje, aby CPU umel instrukci, kterou 50% procesoru neumi (napriklad plati pro vsechny celerony).

Zdroj?

> yzaduje, aby CPU umel instrukci, kterou 50% procesoru neumi (napriklad plati pro vsechny celerony)

O jakou instrukci jde? Celeronů jsou mraky různých druhů.

Možná jsi zůstal Ty a část ostatních Gentooistů zamrzlý ve 20. století. Kompilovat si něco tak obrovského jako Rust a ještě k tomu na Celeronu, to není úplně dobrý nápad. Jestli je alternativou C, tak cha, cha a cha cha. Invektivy nepomůžou, posuňte se z pravěku do dneška. Nebo napiš, proč to všechno potřebuješ na každém stroji překompilovávat, možná mi něco uniká.

26. 4. 2024, 11:32 editováno autorem komentáře

Člověk není ani omylem živ jen tím, co potřebuje.

Opravdu jsou ty S (nebo dokonce T) procesory úspornější? Já o tom v minulosti něco hledal, a co jsem pochopil tak mají akorát zastropované TDP, protože jsou určené do různých bussiness PC s omezenými možnostmi chlazení, ale ve výsledku pro stejnou operaci spálí stejně proudu jako klasika, protože jim to bude trvat déle.

Takhle to nefunguje. Naprosto obecne plati, ze ti spotreba roste s frekvenci spis exponencielne. Takze kdyz snizis frekvenci treba o 10%, muze ti spotreba klesnout klidne i na 1/2. Ale ten vykon klesne vycemene linearne s tou frekvenci.

Ano, je možné získat ještě větší úsporu, pokud i do jisté míry draze spočítáme úlohu rychleji a poté se přepneme do mnohem úspornějšího módu s nižší frekvencí a napětím.

Tak to úplně není. Máme stejný procesor, pořád stejná spotřeba v klidu a teď přijde úloha. Máme ji spočítat na velké frekvenci a rychle, nebo na menší a pomalu?

Čas dokončení bude jako 1/f a spotřeba bude minimálně jako f² (spíš víc). Dokončení úlohy teda bude stát energie f²/f=f. Tedy čím větší frekvence, tím dražší. Ale lidi to prostě chtějí mít rychle no.

Spotřeba by měla zhruba záviset takhle - P = α*C*f*U^2 (α - aktivita, C - kapacita, f - frekcence, U - napětí). Takže problémem některých moderních (nejen) procesorů je, že pro dosažení vysoké frekvence je potřeba neoptimálně vysoké napětí.

Tak on člověk dýchající vzduch za ten čas co čeká na dokončení kompilace má taky spotřebu 100W-120W a ještě navíc jeho čas stojí dost peněz. Mě u procesoru teda víc zajímá spotřeba v idle, kde to tráví 95% času a tady bude rozdíl mít Ryzen 5xxx se spotřebou 50W a k tomu 10W dá herní grafika nebo jestli je to nějaký normální procesor co v idle žere 8W a v zátěži klidně 120W a víc.
Ale co mám bohužel jedno SBC s celerem 3500 nebo tak něco a mini PC s i5-6500T, tak celer žere 2W idle, 7W zátěž. Mini PC žere 6W idle a 38W zátěž. Rozdíl je v tom, že ta I5ka je pětkrát rychlejší, pětkrát tolik sežere, v idle ty 4W nedělají ani za rok moc a dá se s tím normálně dělat - generování náhledů obrázků, načítání webových stránek a rozbalování balíčků při upgradu trvá nějakou lidskou dobu.
Ale pokud mám počítač na vývoj a kompiluju velkej projekt X-krát denně, tak preferuju co nejrychlejší počítač, pokud strávím denně 20 minut pracovní doby tím, že čekám na kompilaci, tak do práce chodím dva týdny ročně zbytečně.

Zde zalezi na generaci. Typicky vsechny procesory, ktere maji BOOST, tak tohle delaji nad ramec sve TDP specifikace, a v tomto pracovnim bode je jejich energeticka efektivita neoptimalni. Ano - dokazou v absolutne kratsim case dosahnout vysledku, ale za nesobne vyssi cenu. A pokud mate slusne chlazeni, tak se budou velice ochotne drzet toho energetickeho ne-optima.

U procesoru S/T je TDP polozeno nize, a je blize energetickemu optimu, takze danou ulohu zvladnou za absolutne nejmene energie.

Ve sve databazi jsem nasel dva podobne 6C/12T cpu stejne generace (8/9 je CFL, CFL-refresh, kde se tunil jen self-OC, jinak stejny kremik):

9th gen: E-2236
~ 6m06s @ 115w 4.1G boost, 9.842 C/hr, 85.582 C/kWh

8th gen: i7-8700T
~ 9m33s @ 51w 2.4G base, boost-off, 6.286 C/hr, 123.253 C/kWh

A to prosim ta i7 jela s GPU, zatimco na xeonu byla externi BMC. Stejne zdroje, podobne pameti. Testoval jsem stejnou metodikou asi 80 systemu.

Zde vidite, ze za 2.25x spotrebu, dosahl xeon jen cca 1.56x lepsiho casu.
C = kompilace kernelu. Energeticka efektivita je pak pocet kompilaci za kilowathodinu, coz je hlavni vystup mych mereni (pohybuje se to od 27 do 217 na hw ktery jsem mel k dispozici - cokoliv se naslo s UEFI, pac jsem uz linej delat legacy boot)

Na te i7 lze povolit boost a zere to 100w/10sec nez se to zahreje (3.8G/10s, pak 2.9G) a vychazi pak efektivita o neco horsi, ale je to rychlejsi no:
~ 7m47s @ 63.4w, 7.712 C/hr, 121.644 C/kWh

Asi víc kompiluju :) Za 14 let mám na tachometru 252d:23h:52m:3s.

Tak to me prekvapilo - 17.5 roku (od 2006-12-20 16:05:36) mam na svem desktopu natoceno pouze 34d:20h:46m:53s :)

Tak začínal jsem na hodně pomalém HP NL42 a často jsem dělal pokusy, které zahrnovaly emerge -e world. Taky se mi zdá, že občas mi emerge zatuhnulo, musel jsem ho zabít, ale čas běžel dál.

V článku chybí ještě jedna věc. Nevím jak na Gentoo, ten jsem nikdy neměl, na FreeBSD si při kompilaci vybírám mnohem víc, než jen obecné volby v make.conf. Per balíček si lze vybrat jednotlivé komponenty (třeba pro ffmpeg sadu kodeků, to jen pro příklad), takže rozdíl v době kompilace mezi výchozí distribuční volbou a mojí osobní volbou je značný. Reálně mnoho hodin vs. pár desítek minut pro celé distro. Tedy update a kompilace nějakého jednoho balíčku trvá třeba 2 minuty. Tedy spálená elektřina na kompilaci není tak velká, pokud si vyberu skutečně jen to, co potřebuju.

Další věc je, že to kompiluju pro konkrétní procesor. Takže takto jsem povýšil procesor z roku 2013 (Bulldozer) na úroveň prvního Ryzenu (2017) třeba právě při převodu videí do h265 pomocí ffmpeg. (Optimalizovaný kodek na bulldozeru vs standardní na Ryzenu.)

Tedy jsem ušetřil za nákup novějšího procesoru.

ano tohle je v gentoo stejne a pokud vim, tak se gentoo inspirovalo prave bsd. v gentoo se tomu rika use flags.

"Další věc je, že to kompiluju pro konkrétní procesor"

Coz ma pomerne zasadni nedostatek. Kdyz ti to umre, nemuzes vzit disk, vrazit to do libovolneho jinho stroje a ono to ... nenastartuje.

Ano. Ale tak co. Nainstaluju default freebsd z binárních balíčků, připojím disk s daty a je to. Zdržení 15 minut. A následně to kdykoliv později překompiluju.

V praxi to tak horké není. Můžu vzít Gentoo kompilované na Ryzenu 5xxx s -march=native, nabootovat to na osm let staré Sky Lake i7. První chvíle, kdy na mě vyskočí SIGILL, je když se pokusím přehrát nějaké video nebo na něco použít ffmpeg, jinak je to všechno přenositelná x86_64, akorát možná špatně optimalizovaná a tak běhá na daném CPU pomaleji než s -march=generic.

Do přechodu na NixOS jsem takhle propagoval všechny svoje počítače, na všech jsem měl gentoo s rodokmenem až do 2006, s desítkou změn hostname v bash_history :-)

Přesně tak. Takhle jsem si na tehdejším dvoujádru zvýšil výkon o desítky procent pro video.
Velmi to bylo poznat už jen při pouhém přehrávání.
A některé operace místo vteřin byly jak blesk.

Ono s tou úsporností novějších procesorů... no :-) Mám Gentoo na Ryzenu 3950X. Běží to brutálně rychle, vlastně jediné co trvá nějakou otravnou dobu je chromium, zbytek je hotový za chvilku. Používat to při práci je s 64GB RAM už složitější, pač zmíněné chromium ji při 32 threadech skoro celou vyžere. Nicméně ta sestava bere (dle wattmeteru do zásuvky) ~100W v idle a ~200W při CPU na 100%.

Tak či tak je to na provoz pořád rychlejší, než Windows. Tam doba aktualizací trvala podobně dlouho jako ty kompilace a po sérii vtipů, kdy mi to vždycky v noci probudilo počítač, aby se aktualizoval a on pak zůstal běžet celou noc (nebo třeba celý víkend, když jsem byl pryč) v promptu Truecryptu, to sežralo elektriky tak o řád víc.

To je ještě dobé, PC s TR 3970X si pápne 160W v iddle a 450W v plné CPU zátěži. To mám změřené. A z recenzí vím, že mnohem novější TR 7970X 150W v iddle a se zapnutou PBO se v plné zátěži lze dostat i nad 600W.

Dává na to ČEZ už sazbu D57D (elektické topení)? :)

No jo, u TR už platí takové to pořekadlo z motorsportu: kdo chce opici, musí mít na banány :-) Ostatně já po něm tenkrát pokukoval a když vezmu že krom ceny CPU i MB byly o dost dražší, tak ta cena za elektřinu je proti tomu pak stejně sranda :-)

Me treba na gentoo chybi moznost instalovat veci jako user - myslim tim neco jako overlay nad zakladnim systemem. Ale chapu ze je to pak dependency hell a proto to tam nemaj (zakladni OS by nevedel, co maj ruzni uzivatele za ruzny sw instalovan)

Naposledy jsem Gentoo pouzival v davnych dobach Athlonu.

A mel jsem zkusenost, ze pri optimalizaci na Athlon pomerne casto padala kompilace, nebo vysledne binarky.
Takze jsem stejne skoncil na urovni 686 a jenom par veci kolem videa jsem udrzoval s optimalizovanyma use flags.

A kdyz jsem si udelal jednoduchy benchmark, binarky od Redhatu byly rychlejsi, nez mnou kompilovane se safe nastavenim 686.

26. 4. 2024, 16:05 editováno autorem komentáře

Já používal Gentoo na i5-2500k, loni jsem konečně seznal, že půldenní kompilace qtwebengine jsou nesnesitelné a pořídil Ryzen 5 3600 (samozřejmě také odpovídající desku, jen jsem teď líný hledat model :-D)

Těsně před výměnou jsem ještě na druhé malé SSD nacpal OpenSUSE, ale se systemd jsem se prostě sžít nedokázal, nějaké aplikace mi v repozitáři chyběly (je vidět, že dost spoléhají na flatpaky) a přidávání repozitářů a následné aktualizace jsou oproti Gentoo dost otravný (eselect repository je naprosto geniální záležitost).

Staré Gentoo jsem nakonec spolu s OpenSUSE smazal (na kterém se po pár týdnech mírně pokakal systemd, kdy při vypínání hlásil nicneříkající hlášku o čekání na session nebo co a vypnutí tím trvalo o 1.5minuty déle. Nikde se mi nepovedlo dohledat, na co to vlastně čeká) a nainstaloval Gentoo znovu čisté (to staré bylo plné bordelu z mých nesčetných pokusů z dob, kdy jsem tomu nerozuměl skoro vůbec - ovšem nutno podotknout, že nejhorší, co se mi za celých cca 10 let rozsypalo, bylo dependency hell u emerge způsobené mnou odmaskovanými/od­keywordovanými aplikacemi, které jsem ale vždycky nakonec dokázal vyřešit).

Navíc nedávno začali dost pracovat na Gentoo binhost, takže se dá provozovat i v režimu "kompiluji jen to, u čeho potřebuji změnit parametry, zbytek stahuju binárky".

To vypínání o pár minut déle může být způsobeno ztrátou nějakého dbus procesu, buď že ho něco zabije (např. oom killer), nebo že se s ním nedá spojit protože došlo ke změně hostname. Ono to pak čeká na timeout.

No zkrátka jsem nedokázal nijak najít důvod nebo zjistit, jak bych se k tomu vůbec dostal. A zkracovat timeout je jenom mírnění symptomu, nemoc by zůstala a stejně bych neměl šajn, co se děje.

OOM to určitě nebyl, paměti bylo vždycky dost (starý PC měl jen 16GB, ale na novém s 64GB jsem tu samou instalaci pouštěl taky, abych nemusel tahat live obraz a hledat v šupleti flashku. To už je jedno, teď jsem zpět na Gentoo s OpenRC a jen si chrochtám. :-D

Tak, tak. A ten timeout se dá nastavit. A někde jsem i viděl změnu politiky, že to sami distribuce později změnily na kratší čas.

To rychlejší vypínání bylo třeba tady: https://www.root.cz/clanky/fedora-zrychli-vypinani-hammer2-na-netbsd/