Hlavní navigace

Vlákno názorů ke zprávičce Rust 1.59 podporuje asembler přímo v kódu od klokan - Nejsem zrovna zastánce inline assembleru. I v rámci...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 25. 2. 2022 8:42

    klokan

    Nejsem zrovna zastánce inline assembleru. I v rámci jedné instrukční sady je optimalizace pro jeden procesor jiná, než pro druhý, a to nemluvím o využívání AVX2, NEONu atd podle toho, co konkrétní stroj zrovna podporuje. Lepší by mi přišlo psát takový kritický kód v nějakém bytekódu (třeba jako LLVM a klidně rovnou jako SSA) a pak ho při spuštění dynamicky přeložit. Koneckonců když to tak funguje pro shadery běžící na GPU, proč ne i v tomto případě?

    Tam, kde je nutné psát vyloženě nízkoúrovňový assembler (např. implementace komutace kontextu pro dané CPU) je už lepší to mít jako samostatný soubor obsahující jenom assembler specifický pro platformu.

  • 25. 2. 2022 13:10

    jdsulin

    Nevim, jak je na tom Rust se simd, myslim si, ze nejakou zakladni podporu ma a to je docela reseni. Z praxe ti muzu rict, ze pokud se nejedna o nejaky vysoce specificky kod, tak je inline assembler docela nepouzitelny.

    Pokud se bavime o simd a akceleraci, tak nejrychlejsi a nejednoduseji pouzivana je asi CUDA, ale ta je nepouzitelna na jinych grafickych kartach, takze pro produkt, kde neurcujes klientovi hw specifikaci nepouzitelne. OpenCL je docela v pohode, az na to, ze se na to o dost hur pise kod, ona kompilace pri prvnim spusteni muze docela trvat - tady funguje zrovna ten bytekod - Spir-V, dobra pomoc jsou i knihovny jako boost::compute, VexCL nebo ArrayFire, ktere jsou takovy slabsi thrust. Problemem je ale fakt, ze pri psani obecneho kodu vlastne nikdy nevis jak velkou mas mit pro ktery hardware workgroup, jestli je tato operace lepsi udelat na CPU nebo uz na GPU, jake verzi, nema driver chybu, proste do vedeckeho prostredi, kdy vis, ze tam mas tohle GPU a nejrychleji to na nem jede takto to neni problem, ale pokud to chces mit jako akceracni plugin, napriklad do programu pro zpracovani obrazku, tak si nemuzes byt jisty nicim....Co ale podle me je nejlepsi reseni z pohledu absolutni jednoduchosti je direktiva OpenMP simd. Nejrychlejsi to nejspis nebude, ale pouziti je velmi jednoduche, resi to navic i vice "devices" -> direktiva parallel to umi rozlozit na vice procesoru a porad to poskytuje docela slusne zrychleni. Jak je na tom Rust s podporou je docela jedno, protoze udelas zakladni implementaci funkci a ty akcelerovane muzes dat do samostatne C knihovny.

  • 25. 2. 2022 21:22

    Vít Šesták

    Pokud by někdo měl v Rustu použít třeba LLVM (hádám, že jste měl na mysli textovou formu, ne bytecode), kdy by se vyplatilo tomu dát přednost před napsáním přímo v Rustu?

    IMHO asm se vyplatí zejména tam, kde potřebuju sáhnout rovnou na CPU, a kde multiplatformnost stejně musí jít stranou. Tam, kde chci kompilátor, aby vyřešil optimalizace a multiplatformnost, dává smysl použít ten Rust. Ale LLVM?

  • 25. 2. 2022 23:43

    klokan

    Samozřejmě, myslel jsem LLVM jako pseudoassembler (tj. textová forma). Psát rovnou v LLVM má samozřejmě smysl málokdy, ale konkrétním příkladem může být právě ten SIMD / DSP kód. Rust sice umí autovektorizovat docela dobře, ale minimálně dneska to není na takové úrovni, aby se dalo spoléhat jenom na to. Má taky bednu simd s příslušnými typy, ale jednak to ještě nekryje 100% potřeb ani možností jednotlivých architektur, a jednak to znamená psát kód pro každý cílový procesor zvlášť. Konkrétně mám několik počítačů, mezi nimi některé mají procesor s podporou AVX2, některé mají jenom AVX a k tomu pár RPi, které mají NEON. Psát takový kód s vektorovými operacemi LLVM by umožnilo, napsat kód jenom jednou, přeložit binárku pro amd64 a jednu pro aarch64, a přitom by dokázaly využít schopností každého procesoru.

  • 26. 2. 2022 20:17

    Vít Šesták

    No, nevím. Neznám detailně vektorové instrukce na různých architekturách. Nicméně jako programátor bych radši volal obyčejnou (safe) funkci než řešil LLVM, a tím zřejmě i unsafe blok. Možnost LLVM (implikuje to kod specifický pro daný compiler backend) by šla využít v nějaké knihovně.