Vlákno názorů k článku
Výkon experimentálního Ubuntu sestaveného pro x86-64-v3
od RDa - To se dalo cekat - ono AVX2 na...
-
To se dalo cekat - ono AVX2 na modernim cpu neprinasi tolik uzitku - je to proste draha sranda - protoze to snizuje maximalne dosazitelne takty.
Smysl by to melo u AVX2 only aplikaci, ktere tyhle instrukce budou vyuzivat velice huste - ne u operacniho systemu, kdy je uziti velice ridke, a rekl bych ze v pripade gcc/stdlib omezene temer na obycejne memcpy/memset. A to jsou spis servisni funce, nez samotne jadro aplikaci.
-
Co říkáš neodpovídá dosaženému zrychlení.
Ber to tak, že AVX2 je z roku 2013 a nemusíš tedy řešit rozdíly ve vývoji do té doby. PŘÍČINA ZRYCHLENÍ tak bude nejspíš v odstranění hromady obezliček pro "před AVX2" procesory z výsledného kódu a další "na první pohled nepodstatné" záležitosti.Prostě nemusíš řešit, jestli a kterou subvariantu AVX máš k dispozici, nebo jestli musíš emulovat dolů na SSE/FMA(E), protože máš k dispozici AVX2 a moderní procesor.
Další benefity budou na té straně, že postupně dochází k rozšíření registrů, kdy na starších procesorech prostě nebylo vždy úplně jasné, jestli lze rozšířené registry použít, jestli v CPU vůbec jsou. x86-64-v3 ti jasně definuje: AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE
Je pravda, že x86-64-v4 se týká už jen 512 bitových registrů (AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL) a není jasné, jestli by to vůbec nějaký přínos mělo. Možná asi ani ne.
-
Nevim kde beres pocit ze to neodpovida zrychleni - proste v beznem kodu je X procent memcpy, a ted je tento kod 2 krat rychlejsi, takze celkovy prinos je X/2 procent vykonu navic.
Zadna distribuce neresi subvarianty ani emulace / nahrazky.
Vzdy je to skompilovany optimalne, vuci urcite urovni architektury. Tj bezne ubuntu bezi na nejakem minimalnim hw, a ta nova rekompilace pod nazvem x86-64-v3 ti vyzaduje hw s AVX2. Ani jedna z techto distribuci neresi runtime detekci.
A dalsi zminena nevyhoda AVX2 je dvakrat vetsi kontext, ktery se musi ukladat pri task switchu (otazka je, zda vzdy, nebo jen kdyz userspace pouzije tyhle instrukce).
-
Runtime detekciu riesi glibc hwcaps. Pokial v systeme existuju binarky pre jednotlive mikroarchitektury, tak dynamicky linker natiahne tu optimalnu.
Takze nic nebrani mat -v2 pre starsie systemy, -v3 pre novsie a -v4 pre tych zopar, co maju AVX512 a vsetci mozu byt spokojni (okrem builderov, ktori musia skompilovat binarku 3x).
-
x86-64-v3 je imho mnohem menší problém, než se zdá. Přechod na x86-64-v4 by byl, jelikož Avx512 nemá/nemělo spousta "aktuálních" cpu. Třeba do mobilních cpu je intel nedával a amd se dlouhou dobu avx512 vyhýbal obloukem. Navíc pokud si dobře pamatuji, tak použití avx512 bylo u intelu z počátku hodně energeticky náročné a kolidovalo s turbo boostem, takže možná ten přidaný výkon nakonec z hlediska spotřeby není o moc výhodnější.
-
Je to nabušený procesor, který si poradí - narozdíl od Cortexů - i s neoptimálním kódem. Takže není třeba moc optimalizovat. Ale i tak je Apple např. hlavním tahounem vývoje kompilátoru LLVM a těží z toho i ostatní zařízení s ARMem. Pokud jde o akcelerátory, Apple má narozdíl od AMD stejně kvalitní SDK jako třeba NVidie, takže pro vývojáře je to radost přidat podporu do svého software. AMD např. dodnes nemá funkční ani výpočty na GPU na většině jejich grafik. Natož nějaká podpora AI nebo enkódování videa.
-
DannyStříbrný podporovatelTo nemusi byt nutne proprietarni vymysly. I linuxovy kernel je plny errata a quirku k ruznym specifickym bugum konkretnich hardwarovych platforem. A proste to nechcete aplikovat plosne, kdyz by to melo degradovat vykon tam, kde to neni nutne.
