Vlákno názorů k článku
Microsoft přepisuje části Windows do Rustu
od Bez přezdívky: - Kdyby to napsali v assembleru, maji zvyseni vykonu...
-
"Trochu" víc, tohle není Apple. Navíc se sníží výdrž baterie na polovinu, na úroveň strojů s x86 (které zas nabízí kompatibilitu). Emulace ve Windows je totiž nekonečnou smyčkou vytěžující CPU na 100 % (stačí tedy mít trvale spuštěn jeden x86 program). Na Applu (Rosetta 2 pro macOS a Linux) a Alphě (FX!32) se program zkompiluje (Ahead-of-Time) do cílové architektury, takže vlastně spouštíš nativní binárku (ta samozřejmě běží o něco pomaleji než nativní program, protože jsou do kódu generované různé pomocné instrukce). Na Itaniu nevím, jak to funguje.
-
Dobrý na Windows a Apple je, že systémové knihovny se používají nativní. Aktuální podoba qemu-user na Linuxu emuluje i systémové knihovny (musíš mít nainstalovanou jejich x86 verzi, takže dokonce zabírá víc na disku; řešení je rozpracované a zatím v nedohlednu - nicméně funguje tam Rosetta 2, chybějící přepínač CPU pro strong memory model x86 lze obejít tím, že všechna vlákna aplikace, pokud jich má víc, dáš na stejné jádro). No prostě čím víc tvá aplikace používá kód z knihoven OS, případně GPU, tím víc toho jede nativně na Windows a Macu.
27. 4. 2023, 21:55 editováno autorem komentáře
-
Vždyť to jsem napsal :-) Rosetta 2 právě využívá toho, že Apple CPU umí x86 strong memory model. Ale i bez něj lidi vesele používají Rosettu 2 na Linuxu (Apple ji oficiálně vydal i pro Linux - primárně pro x86 Docker images na macOS) na Cortex jádrech, které to neumí. Stačí se zamyslet, k čemu strong memory model slouží a obejít to pro aplikace, které běží na více jádrech (pro jednovláknové aplikace bez práce).
28. 4. 2023, 00:07 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatelKdyby to psal v assembleru stejný počet lidí, nemají nic. Kdyby navýšili počet lidí adekvátně tomu, o kolik těžší je psát v assembleru, pravděpodobně by měly pomalejší kód. Protože kompilátory už jsou nějakou dobu v optimalizaci lepší, než i ti lepší programátoři. Samozřejmě že kdyby to psali ti nejlepší z nejlepších, dokázali by to v assembleru občas optimalizovat lépe (protože ti nejlepší z nejlepších by mimo jiné neměli problém nechat si to přeložit kompilátorem a použít jím vygenerované optimalizace) – akorát by to trvalo tisíc let, než by všechen ten kód ručně a ve špičkové kvalitě napsali.
-
Protoze GPU nema task switch a potrebu odkladat desitky kilobajtu TSS, resp. je tam nejaka hw podpora pro prepinani threadu.
Az bude mit GPU podporu pro MMU, TLB, vyjimky/restart, paging a swapovani, a nabootuje Linux, tak muzeme srovnavat srovnatelne. Do te doby je gpu pouha jednoucelova hracka - resp takove nacancanejsi DSP (jestli si je nekdo pamatuje, at uz od ADI nebo TI)
-
Já mám zkušenost jinou - pokud se jedná o nějaké distributed věci, které jsou obrovské, je tam nějaký network overhead, atd... tak AVX-512 je jednoznačná volba - programuje se pro to skvěle, debuggovat se to dá taky hezky a jako bonus je to na každém commodity HW co má X86 architekturu (Xeon a nově i Epyc od AMD) - člověk si může rentnout obrovský cluster v podstatě bez limitu. S GPU je to mnohem horší - je to drahé a dostupnost v cloudu je hodně omezená, protože každý chce GPU na ML...
Já jsem se teda setkal s AVX-512 kódem pro kompresi/dekompresi dat, regex engine, JSON parsing, XML parsing, a různé další věci pro big data processing. Když je zrychlení oproti C třeba 10x a problém začne být network bandwidth, tak je práce v podstatě hotová.
