SUSE je v tomto asi najpokrokovejšie = ašte len bude
OpenSUSE Tumbleweed Might See Micro-Architecture Packages For Better Performance
Written by Michael Larabel in SUSE on 8 March 2021
Proposed ahead of this year's SUSE Hack Week 20 event, which runs the last week of March, is supporting glibc-hwcaps and providing micro-architecture package generation support for openSUSE Tumbleweed and down the line for SLE/Leap
https://www.phoronix.com/scan.php?page=news_item&px=OpenSUSE-Micro-Arch-Packages
Predstavte si to tak, ze v programe (napr. encodovac videa) su funkcie:
- encodeUsingMMX()
- encodeUsingSSE()
- encodeUsingAVX()
Tela tych funkcii su C kod s embedovanym assemblerom, ktory vyuziva vyssie uvedene instrukcie.
Predtym nez zapocbe vypocet, program zavola cpuid() alebo pod. a zisti si instrukcnu sadu procesora, na ktorom bol program spusteny. Podla toho sa rozhodne, ktoru funkciu zavola na vykonanie vypoctu.
Ne úplně se mi to líbí, jelikož v budoucnu to odřízne spoustu strojů, které můžou běžet a sloužit ještě několik let, ale na druhou stranu dle statistiky ze Steamu nejběžnější CPU v desktopu je Haswell, což opravdu odpovídá tomu AVX2.
Já se ale trochu bojím toho, že jak tím totiž začne jeden tak se toho chytnou všichni a ne každý bude mít stejné limity, a brzy budeme mít situaci kdy i "hello world" bude vyžadovat minimálně avx512 protože je to přeci IN.
Arch Linux je docela oblíbená distribuce třeba na malých VPS a různých jiných limitovaných strojích. Na vlastním VPS mám taky 512 MB RAM protože víc na VPN a poštovní server (plus mínus) prostě nepotřebuji.
Jenomže když tam přijdete s instalačním obrazem Arch Linuxu, ani ho nenabootujete. Jsou sice metody jak ho tam dostat přes jiné distribuce, ale asi chápete, že to není zrovna komfortní. Nebo tedy spíš je to dost úlet. Já jsem se na to následně vykašlal rovnou a po mnoha letech přešel na Alpine Linux.
Takže ano, trápí.
Já zase nechápu, proč bych na ni strkal třeba Ubuntu Server nebo nedejbože Debian. Ne, flame tohoto druhu nemá smysl. Chápu obojí; každému vyhovuje něco jiného, Ondro. Nemluvě o tom, že v téhle kategorii často jde o osobní servery, hobby servery, nějaké malé pomocné servříky a podobné, kde vám to může být srdečně jedno.
Arch Linux ostatně primárně opravdu není desktopový systém.
Záleží, co si představujete pod komfortem. Mně nabootovat z image, vytvořit a naformátovat partition, nabootstrapovat jedním příkazem systém, nastavit síť a SSH a restartovat přijde jako dost primitivní.
Primitivnosti ale značně přibyde, pokud tohle musíte komplikovaně řešit přes něco jiného. A jelikož reálně musíte jenom umřít, mohu použít rovnou něco jiného.
Jestli jsem se díval dobře tak Haswell je z roku 2013, to máte 8 let starou záležitost. A o úplném odříznutí starších procesorů se tam nepíše... Pokud na novějších strojích bude lepší výkon, tak mi to přijde jako fajn.
Já ntb měním cca po těch 8 letech. Manželka má můj starší ntb, který má letos přesně 10 let a je pravda, že morální zastarávání se už začalo dost projevovat. Windows 10 tam nelze rozumně rozjet (funguje, ale je problém s grafikou). Má tam Manjaro, které tam sice funguje fajn, ale třeba nelze povýšit jádro na vyšší než 5.4 kvůli HW, jak se domnívám. Jakmile přestane být tahle verze podporovaná, tak to asi půjde do šrotu. Představa, že ty stroje budou provozovány do vyhoření je dle mě nereálná.
To s tím jádrem je WTF, to je kvůli proprietárním ovladačům grafiky?
Notebookové Sandy Bridge a starší jsou už trochu pomalé zejména kvůli dnešnímu webu/browserům, ale pořád to může dělat ne-browserový servis. Ale desktopové Sandy Bridge jsou ještě v pohodě.
No a pak tu je hromada nových počítačů bez AVX2, dokonce koukám i bez AVX (!). Notebooky a tablety s Celerony a Atomy a embedded věci jako PC Engines APU (AMD Embedded G series GX-412TC - to má AVX, ale ne AVX2).
Ano, nejspíš je to grafikou, ale je to celé divné a já řešení byl ochoten věnovat zatím pouze několik hodin.
Je tam kombinace intel grafiky a nvidie (již bez podpory) které jsou jaksi propojeny, takže jedna jede přes druhou. Přijde mi to celé jako pěkná pi..., kdybych při koupi věděl, že ty grafiky nedokážou fungovat bez sebe, tak bych to nekupoval.
Jinak, ovladače nvidie jsou už na ntb samozřejmě pouze nouveau. Ale prostě s novějším jádrem nelze nabootovat do graf. rozhraní, přestože je nvidia není ani primární grafikou. Z čeho mi vyplývá, že vlastně ani nechápu k čemu nouveau je dobré, když legacy grafiky asi taky nepodporuje a na grafiky, které ještě podporuje nvidia nabízí ovladače s brutálním poklesem výkonu...
Btw. když jsem tam zkoušel dát Win10, tak jsem zjistil, že Intelem neni už podporovaná ani ta jeho HD grafika :D. Nativní rozlišení monitoru je 1366*768 a jediný režim, který šel spustit byl 1280*720.
17. 3. 2021, 11:54 editováno autorem komentáře
Poprosil bych asi, abyste ten notebook, až vám přestane vyhovovat, poslal dál. Pořád ještě máme v ČR několik tisíc dětí (možná i desítky tisíc), které se nezúčastní výuky, protože nemají prakticky žádný HW. A Haswell by minimálně jako základ mohl stačit (i ten Zoom nebo gmeet bez vysílání videa by šel). Doma takto celkem provozujeme jeden starší šrot, už bez baterky, ale při nutnosti provozu pěti počítačů zaráz pořád dobrý :-)
jj plně chápu. No v každém případě I5+4GB RAM+HDD je ve školství velmi dobře hratelná kombinace. Jít níž (méně RAM) je asi problém.
FYI: Ona je totiž ta situace fakt dost problematická. Na jednu stranu se zvýšily nároky na to mít vůbec nějaký hardware ze strany dětí, další lidi šli na home office, firmy (zdá se) kvůli jiným problémům prodlužují obnovu HW (takže jde míň starších počítačů na trh - typicky býval dobrý nákup starších desktopů z bank) a ještě i hráči mají vůbec problémy sehnat nový HW za rozumnou cenu (takže taky nepouští starší sestavy do oběhu).
Ted uz se v mistech narazi i na omezeni konektivity i pokud clovek venuje HW. Venoval jsem dva notasy do socialne slabych rodin v okoli. Bohuzel site jsou v miste nechutne vytizene a ne vsechny domy vidi na nejaky bod nasich wifinaru. Fixni LTE vodafonu pada pod 10Mbit.
Prave vyhrozuji starostovi ze jestli do roka nebude mit plan odstehuju se. Nabidl jsem soucinnost a pomoc s poptavanim organizaci, technologiemi, dotacemi a spolufinancovani aspon pristupove site v nasi ulici.
V nedavne dobe jsem ale slysel argument na ze 3G a KLFree staci. No a s takovymi lidmi clovek jedna kdyz ma vsude stin a pevna linka chybi v nekterych castech obce zcela.
17. 3. 2021, 15:17 editováno autorem komentáře
To se dělá už velmi dlouho, u funkcí kde to dává největší smysl a maintainer si s tím dal tu práci. (například řetězcové operace v glibc)
Taky bych dodal, že benchmarky pro různé matematické a grafické operace nemusí moc vypovídat o výhodách při ostatních/"obvyklých" použitích. Je to pak otázka... troufám si tvrdit že pro drtivou většinu kódu v distribučních balících nemá smysl dělat druhou variantu, protože zisk je v těch částech malý a ta duplikace něco stojí (protože úplně ignorovat starší CPU jistě nemohou). Samozřejmě, kdo si kompiluje jen pro svůj stroj, ať si dá -march=native/whatever.
17. 3. 2021, 21:10 editováno autorem komentáře
Prece jim nic nebrani linkeru slinkovat kod dokupy tak,a by vnikly 'segmenty' ktere nebudou rozvalcne a budou obsahovat prave to co se aktualne pouziva. Krom toho, dneska se stejne drtiva vetsina resi prez PIC, tak by nebranilo ani nic celemu OS 'prerovnat' binarku dle aktualniho CPU (coz muze ale nocni mura pri heldani problemu, na druhou stranu, vzhledem k ruznych randomizacim stacku a adres uz by to asi stejne bylo putna :)
P.
Ja jsem pro. Predpokladam, ze je to hlavne o penezich (misto na disku na balicky dalsi architektury a cas straveny generovanim novych balicku). Pokud ty penize maji, tak je to jednoznacna vyhra. Mne prijde vazne lito, kdyz clovek koupi nabusenej pocitac s nejnovejsim procesorem a jeho instrukcni sada neni vyuzita ani z poloviny...
To mi chceš povedať, že je problém automatizovať kompiláciu balíčkov?
Tá je už dávno automatizovaná :) ...skus vygooglit termín "continuous integration".
Taktiež si nemyslim, že by bolo treba nejak extra investovať do novej architektúry,
tá predsa zostane tá ista x86_64. Len sa pridaju "code paths" pre nove CPU, čo zväčší o par KB/MB binarky.
Hlavná tiaha padne na vývojárov compileru (teda pokiaľ compiler dynamic scheduling nepodporuje).
Rikam si kam tento svet speje ... na reseni tohoto problemu a multi-arch knihoven by byla krasnym resenim FAT BINARY, jen by se verze x86_64 pridaly jako dalsi "architektura" (resp. nejaka subarchitektura, zjednodusuji, tech polozek na matchnuti by to chtelo asi vice). No a dynloader by si vybral nejlepsi moznost, takze by nic nebranilo aplikaci pro zakladni x86_64 aby se propojila s glibc ktere ma strcmp pres nejake AVX apod.
Fat Binary sa používajú keď chceš vytvoriť jednu binárku pre niekoľko rozdielných architektur, narp x86_64 a PowerPC, alebo x86_64 a ARM64. Pozri wiki: https://en.wikipedia.org/wiki/Fat_binary
Dynamic Scheduling ti zabezpečí, že bude jedna binarka jednej architektúry, ktorá bude mať v sebe "navyše" niekoľko ďalších "code paths" pre procesory, ktoré podporujú dané inštrukcie.
Presne tak ako vravíš. HWCAPS je novinka v GLIBC 2.33, ktorá vyšla 1. februára 2021, čiže predpokladám, že dosť málo ľudí o tejto feature vôbec vie.
vid link na phoronix: https://www.phoronix.com/scan.php?page=news_item&px=Glibc-2.33-Coming-HWCAPS
Fat binary umi libovolne kombinace, ale to neni podstatne, jak pise nekdo nize mechanismus jde pouzit i na ty verze x86_64. Nevyhoda je ze by se duplikovalo dost kodu
Uplne nejspravnejsi by myslim byla fat binary a neco na zpusob tech HWCAPS (jak pise zase nekdo dalsi vyse) kombinovany s individualni exportni tabulkou symbolu. To by zajistilo myslim nejmensi overhead.
Kdykoliv někde zmíníte Ootneg, hned se vyrojí tlupa evangelistů, kteří Vás budou přesvědčovat, že jen ztrácíte čas a že to za ten zisk jednotek procent nestojí. Vy, jakožto dlouholetý uživatel Ootnegu (a možná i přispěvatel) můžete argumentovat benchmarky ukazujícími na skoro dvojnásobný výkon třeba ffmpeg+vp9, ale to jim huby nezavře :-)