Názory k článku
Rust 1.59 podporuje asembler přímo v kódu

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.

Ten “dynamický překlad” má OpenCL (kromě GPU i pro CPU), ale asi má smysl jen pro SIMD.

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.

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?

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.

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ě.

K čemu že je dobrý "bezpečný" programovací jazyk, když si stejně můžu dělat, co chci, v assembleru?

Protože rust na mcu. A co chcete můžete dělat už v unsafe.

Nebo zavolat knihovnu napsanou v C. Což se momentálně v Rustu často děje.

Tohle je na Rustu fajn, C FFI je “zero cost”. Osobně se unsafe a knihovnám v C vyhýbám jak čert kříži, ale když není zbytí, jde to hladce.

A k čemu je to teda dobrý na MCU? Na MCU potřebuju většinu času dělat něco "unsafe", navíc MCU stejně nemá MMU a podobný blbiny, takže bezpečný jazyk na to v zásadě existovat nemůže.

Co staré dobré "lépe se to píše".

Právě proto, že nemáte MMU, potřebujete provést co nejvíc důkazů správnosti už během překladu. Protože v runtime vás už nic nezachrání.

Nejde jen o paměť, Rust řeší i věci jako nastavení periferií, problémy jako že nějaká funkce někde změní režim GPIO a jiná přestane fungovat jsou eliminovány.

K čemu je dobrá střecha, když občas musím ven, i když prší?

25. 2. 2022, 12:07 editováno autorem komentáře

Lepší je spolehnout se na stdlib, jinak můžu stejně “bezpečně” použít C++.

To můžete vždycky. Např. Go pokud vím syntaxi pro inline assembler nemá, ale není problém napsat něco v assembleru, přeložit to zvlášť a pak to slinkovat.

Jo, v Go se dají míchat soubory v Go, C a asm v rámci jednoho buildu. Ale nebývá to dobrý nápad, pokud člověk nepíše něco hodně specifického třeba pro AVX-512 nebo tak něco, protože Go občas kopíruje celé zásobníky a vůbec se chová divně (ve smyslu C ABI). To už je lepší volat třeba Fortran :)

Tak ono je vůbec problém míchat C nebo asm s jazyky, které používají GC. I když zrovna Fortran taky není ideálně kompatibilní, např. pokud si pamatuju (už je to strašně dávno), matice jsou tam uložené po sloupcích a ne po řádkách jako v C, což je taky dost velký opruz.

Jenže ty problémy v Go nijak nesouvisí s GC. Ani tam bych ale netvrdil takto obecně, že míchání C (potažmo C++ nebo Rustu) s jazyky s GC způsobuje problémy, některé knihovny/platformy to řeší poměrně rozumně a prakticky (namátkou C++/CLI, ObjC++, JSCore).

U Fortranu si už nepamatuju podrobnosti, ale není row-major jen volitelné?

Jen odbočka do historie, to uměl i Turbo Pascal. Vzpomínám si na gympl, kdy jsme se s klukama bavili, kolik náš program obsahuje zeleného kódu (před 30 lety nešlo o ekoligii) - syntax highlighting zobrazoval assembler zeleně.