Vlákno názorů k článku Zpracování hodnot typu half float (fp16) na platformě AArch64 od atarist - Kde se to používá? HF jsem viděl u...

Kde se to používá? HF jsem viděl u LLM a třeba na x86 to nebylo vůbec rychlejší než třeba "float" varianta. Na druhou stranu jsou i LLM s bajtovými váhami (ale nevím, jak to funguje vevnitř).

Pro embeddings. Tam je AArch64 úplně super. Samozřejmě ne tak rychlý jako GPU, jenže GPU jsou v čmoudu drahé/nejsou k dispozici, takže si na to beru vždycky mašinu s AArch64 a pomalejší x86-64 nechám pro ostatní (asi s Windows :-). Taky se s tím dají přežít SW-only LLM s half-float (tedy záleží na tom, na co, ale někdy fakt není GPU k dispozici).

Mimo neuronové sítě se používá v grafice, ikdyž je fakt, že většinu toho desktopový SW počítá na GPU, kde ARM nejspíš nepoběží. ;) Na druhou stranu, hodí se to třeba na MCU, který bere obraz z kamery a potřebuje provést nějaké zpracování – rozsah 8bitového integeru se do half-floatu vleze bez potíží a navíc si program může dovolit používat výrazně větší dynamický rozsah bez toho, aby hrozilo přetečení celočíselného typu.

Další oblast je zpracování jiných signálů, například data ze senzorů – přesnost half-floatu by mohla postačovat například na zpracování dat z akcelerometru, senzoru osvětlení, …

Pak mě napadá zvuk. Ale převod z 16bitového floatu do 16bitového integeru vypadá dost bolestně…

to mi připomnělo, že s typem half float jsem se poprvé kdysi setkal v Cg a později v HLSL (jazyky pro psaní shaderů).

Já pro změnu v GLSL. Při výpočtech barev na GPU se half-floaty fakt hodí, protože barvy typicky není potřeba počítat přesně, narozdíl od transformací.

Vzhledem k tomu, že NEON, narozdíl¹ od x87, (předpokládám) provádí pro half-floaty jednodušší výpočty, to zrychlení se může hodit. Bylo by zajímavé řešit s NEONem renderování 3D objektu na MCU (bez GPU). Jako use-case si představuji třeba náhled modelu² před tiskem na 3D tiskárně.

¹ Na x87 se floaty počítají vždy 80bitově (tzn. ještě širší než double), na požadovanou délku se ořezávají až při ukládání. SIMD instrukce na x86 to už mají jinak. (Jestli to je implementováno opravdu na méně cyklů netuším.)

² Ikdyž, náhled se daleko snáz dělá ze STL(-like) souboru, ale k tisku je potřeba ho naslajsovat, typicky do G-code příkazů. Ty je už trošku problém vykreslit vystínované a přitom efektivně.