mr.qeg píše:Otázkou je, zda takový stav nastane ve světě obecného SW. 128SSE už teoreticky může být dostatečné a na zbytek stejně bude lepší ten akcelerátor, ať už GPU či nějaké FPGA přímo ušité na míru konkrétnímu algoritmu.
Linus má iirc názor že 128bitů není ještě sice úplně "dost pro každého", ale 256 bitů (AVX2) zase už nepřidá až tak moc, takže zůstat na 128bitech by nebyl úplně blbý nápad, tj. jako ARM s Neon před příchodem SVE.
Jinak ale instrukce SIMD v procesoru nemají stejné využití jako akcelerace na GPU, takže ač se to často říká, tak je chyba říkat si, že nejsou třeba, protože GPU. Některé aplikace GPU zastoupí, jiné ne.
Třeba x265 nebo x264 by se na GPU nedalo udělat. SIMD instrukce v procesoru je přístupná okamžitě s minimální latencí pro jakýkoli program běžící na CPU - nepotřebuje žádný ovladač nebo stack, takže různé výkoné rutiny se dají krásně zapracovat do programů a o tom je všechna ta optimalizace v assembleru. Zatímco když chcete něco offloadnout na GPU, tak se musí vyskočit z toho běžného vykonávání kódu na procesoru, zavolají se nějaké vrstvy OpenCL nebo Cuda, teď to snad kolikrát i jede přes kompilátor v GPU ovladači...
GPU je užitečné když mám velký kus kódu, který potřebuje ten výkon a běží na tom GPU poměrně dlouho, než se ten výsledek bude tahat zpátky do toho mateřského programu na CPU. Když chcete jenom optimalizovat nějaký menší prvek CPU programu, tak se to použít nedá, protože overhead je masivní.
mr.qeg píše:Co se týká přístupu raději 4/2x128/256bit vektorových ALU, než 1x512. Je to podle mě spíš o době, kdy to nasadit. Až se postupně bude více rozvíjet SW a bude obecně více SW umět využít 512b ALU, tak bude jistě lepší ta.
Ono je to o tom, že není výběr mezi 4x128bitů (SSE nebo lépe AVX2 ve 128bitové formě) a 1x512. Jako na jednu stranu je ta první možnost hrozně výhodná, protože zrychlí i všechen legacy kód bez modifikace, což je super. Jenže - když se SIMD operace provádějí rozsekané na víc 128bitových částí, tak pak zabírají místo navíc ve všech frontách, konzumují šířku v různých fázích vykonávání, a pak samozřejmě to znamená, že máte místo jednoho 512bitového portu a jednotku v procesoru čtyři paralelně a na to musí být navržené všechny ty fronty/buffery, schedulery a tak dál. A to je komplexita navíc, která není snadná a má svoje ceny.
V případě, že mám volbu mezi 4x128bitovou pipeline (ALU) a 1x512 tak je určitě lepší nápad to první, už jenom proto, že bych jinak měl mizerný výkon v SSE kódu (jenom jedna operace za cyklus).
Jenže architekti právě nechcou 1x512, oni by chtěli 2x512, 3x512 nebo líp 4x512 (i když 3-4x za cyklus by jádro třeba umělo zpracovat jenom sčítání, logické operace a tak, ne MUL nebo FMA).
No a to pak ta alternativa je 8x128bitová pipeline, 12x128bitová pipeline... a to už je rozhodně příliš velká komplexita a průser na realizování.
Takže v tomhle bodě je určitě lepší místo 8-12x 128 jít aspoň do AVX(2) a rozšířit vektor na 256 bitů, takže budu mít jenom 4-6 SIMD pipeline, což je mnohem snazší (i když 6 už je dost, to asi zatím nikdo nedělá, teda ne když se nepočítají load/store jednotky - výpočetní instrukce umí myslím i Zen 3 i Tiger Lake všechny maximálně 4x za cyklus).
4x256 bitů je podle mě nesporně užitečná věc, to stojí za to do procesoru dát. No ale právě potom když se má SIMD výkon rozšiřovat dál, tak logicky zase přichází ten problém přílišného počtu pipeline, takže 512bitové SIMD vektory jsou logická další cesta. Ice/Tiger/Rocket Lake pokud vím umějí některé ty 512bitocé instrukce s propustností 3x za cyklus a nevím jistě jestli některé ne i 4x, což by se nedalo tak rozumně udělat s AVX2, protože by muselo být 6-8 ALU pipeline, takže zase začíná být problém.
Ty porty/ALU pipeline jsou prostě drahé, takže je lepší zvýšit SIMD výpočetní výkon jedné pipky něž přidávat další.
Ten problém je samozřejmě jestli to consumer software pak může někde upotřebit a/nebo jestli budou mít programátoři vůli to dělat... v serveru/HPC tam je asi celkem jasné, že to nějaké využití má.
) a zároveň to dokáže rýchlo spracovať 512b, ak sa náhodou taký typ úlohy objaví (aj keď prakticky to tam ide cez iné akcelerátory). Dokonca aj AMD tam má určitú flexibilitu.
