Názory k článku Google daroval protokol A2A, Ubuntu mění podporu RISC-V

MS, Windows a taky Apple svet se ma co ucit od Ubuntu, jak se nuti lidi migrovat ze stareho HW na novy.. nevadi ze novy neexistuje, uz ted vam rikame ze mate se starym smolika :D

Krasnej paradox.

A kdo ten RISC-V používá?

Když vyhodím pryč super embedded use-cases (tady bych zařadil i nVidia a spol) tak to nikdo reálně nepoužívá, protože není žádný výkonný RISC-V HW. A přitom někteří vyčítají firmám, že chcou přejít na x86_64-v3 po 10 letech co to je na trhu - toto je paradox...

A když si člověk přečte proč, a co ten nový profil garantuje (třeba SIMD nebo virtualizaci), tak důvody jsou jasné...

Číňania majú Milk-V mars, čo je cca na úrovni raspberry pi 4 plus múnus autobus. To už je použitelné. Len keď som si to chcel objednať, tak poštovné by ma vyšlo viac, než ten počítač. Tak som sa na to vykašlal.

Mám obavu, že jádra RISC-V poskytující nové instrukce hlavně notně nabobtnají a zaberou větší plochu křemíku, zvýší se jejich spotřeba a zmizí hlavní výhody oproti x86 a ARM. Což bude rána pro jejich konkurenceschopnost a využitelnost.

Není to dlouho, co proti ultraširokému AVX512 brojil Linus Torvalds a máme to tu znovu.

Myslím, že to zasáhne zejména startupy a průkopníky typu firem Tenstorrent, která pro své pozoruhodné účely potřebuje na jednom čipu mnoho malých (i velkých) jader s dobrým poměrem výkon/cena pro flexibilní sdílení výkonu na čipu.

Není hlavní výhody oproti x86 a ARM cena?

To určitě ne. Spíš otevřenost a rychlost vývoje. Cena taky, ale jen okrajově.

Tak dnes je celkem běžné, že CPU má SIMD instrukce.

AVX-512 je aspoň použitelné, to se zatím o SVE/RISC-V V moc říct nedá.

To jistě, ale je to nutné, protože výkonnost RISC-V by třeba proti Applíkovým CPU nebo Snapdragonum byla mizerná. Tudíž i neprodejné.
Zatím co vím, tak se používají jen jako pomocné CPU třeba v Pico2, samostatné SOC jsou prostě nekonkurenční.

Máte pravdu, výhodou RISC-V je hlavně cena, případně cena výkon. Někde jsem četl, že pro stejný výkon RISC-V stačí asi čtvrtina plochy čipu starší architektury.

Řekl bych, že vektorové instrukce zvyšují hlavně desetinný jednojádrový výkon, ale v budoucnu se stejně uplatní hlavně mnohajádrový výkon, ať již to bude v mobilu, desktopu nebo superpočítači. Protože dostupný mnohojádrový výkon jednou přijde. Také kvůli tomu je tu programovací jazyk Rust, prohlížeč Servo, standard OpenMP a další.

Myslím, že vektorové instrukce jsou proto trochu cesta stranou, pro krátkodobý bonus, zatímco malá mnohojádra jsou všestrannější.

Navíc, RISC-V výrobci nespí a vyvíjejí stále výkonnější jádra, která v řádu jednotek let výkonově dotáhnou ta obrovská x86 jádra.

x86 jádra jsou podle mě spíše doménou desktopu, ale jinde, třeba nejrůznější servery (web, db, ...) a mobily, upotřebí poměr výkon/cena, zejména paralelní.

8. 7. 2025, 11:41 editováno autorem komentáře

DarovA2Anému koňovi nepozeraj na zuby.

A niečo k RISC-V V

https://mailman.videolan.org/pipermail/x265-devel/2025-July/014442.html

Podle mě hlavní výhoda RISC-V třeba oproti ARMu je, že si tam každý může dát vlastní instrukce, toto třeba ARM nechce (ale Apple to stejně dělá). Pak samozřejmě cena - nVidia taky nechce platit licenci ARMu pro každý jejich RISC-V čip, kterých vyrobili miliardy. Jenže tady je to ale - používá se to na super embedded účely.

Neřekl bych, že výhody RISC-V jsou ve výkonu, protože kdyby byly, tak už tu budou výkonné RISC-V čipy. Poměr cena/výkon teď vyhrává aarch64, na druhou třeba X86 nabízí AVX-512, což je nejpokročilenší SIMD, který teď existuje (SVE nebo RISC-V V proti AVX-512 nemají šanci).

Jinak ne - vektorové instrukce nejsou cesta stranou... Je to způsob jak zvýšit hrubý výkon CPU a zaplatit za to celkem malou cenu. SIMD jednotky zabírají pořád o hodně míň místa než třeba L1-L3 cache a dají se využít i na tak triviální věci jako crypto nebo hash tabulky, atd... Správné použití SIMD dokáže snížit latenci, a to je moc důležité jak pro servery tak pro ostatní segmenty.

Tak reseni kdy ARMu nemusite platit za licenci je spousta - klidne si embedded core muzete psat vlastni - coz ostatne NV pred pouzitim RV delala. Problem ktery tohle nese je dvoji - potrebujete opravdu dobre verifikovat ono jadro / reseni, coz stoji hodne penez, a pak potrebujete drzet team, ktery bude delat toolchain.

Oboji se u RV outsourcuje na komunitu - nekdo tvori jadra a ty pro FPGA jsou dostatecne otestovana (vyjimecne se najde i ASIC ready ready.. ale to je spis domenou uzavrenych nabidek, ne opensource). A pak hromada lidi tim samotnym pouzivanim prispiva k protestovatelnosti kodu ktery dela toolchain. Samozrejme se tady bugy najdou, klidne nejake corner cases - ktere se pak opravi.

Nejvetsi riziko uzavreneho custom reseni je, ze to zdanlive funguje - az udelate nejakou zmenu a cele se to rozpadne protoze to melo urcite vedlejsi ucinky. Tohle je videt velice casto u noveho HW s neodladenym FW, kdy beta testing delaji uzivatele.

9. 7. 2025, 14:01 editováno autorem komentáře

Vektorové (SIMD) instrukce jdou krůček ke grafickým kartám. Ano, mít více jader je univerzálnější, ale když využijeme SIMD, může to být naopak vhodnější než mít více jader:

1. Energetická efektivita – overhead s dekódováním instrukce proběhne jen jednou.
2. Nejspíš overhead pro synchronizaci v případě malých vektorů.

To by mně zajímalo, jak si představují tu podporu záchrany Btrfs. Že bych konečně upgradoval svoje zařízení na tento fs? Bude to fungovat třeba i v umounted stavu (když se mount nedaří)?
Btrfsck to spíš pak už jen dokázalo dorazit (po negativních zkušenostech mám všude opět už jiné fs např. ext4).

A jaky byl mechanismus poskozeni u vas? Nevhodne vypinani, nebo pochybny odpojujici se disk nebo disk co neukladal co ukladat mel? :)

Tak na Turrisu se mi za 7 let pouzivani btrfs rozpadl nejmin 2x. Vetsinou tak, ze nejak umrely metadata, takze zadny nastroj pro obnovu ani nepripadal v uvahu, vsechny me posilaly do haje. Musel jsem preformatovat a pak zase FS par let dobre fungoval na tom samem HW. Ale je pravda, ze to jeste bezelo na jadrech 4.x, takze je proste mozne, ze jsem zrovna vyhmatnul nejaky kernel bug.

Vypínání u notebooku. Například, když už byla dost vybitá baterie, tak při větší zátěži chcíplo. Asi dvakrát jsem to pak pomocí utility z readonly partition překopíroval na externí disk a systém z toho znovu obnovil. Pak mně to přestalo bavit a dal jsem tam ext4 a od té doby je klid.

Jo a dodám, kernel byl už určitě řady 5, není to zas tak dlouho, žádný nějaký starodávný se známými bugy.

24. 7. 2025, 13:13 editováno autorem komentáře