Ach jo, to je zase zavadejici clanek. Rekneme, ze SiFive jde na vec podobne jako Intel s ADL, ale v opacnem smeru. SiFIve ma v performance rade jader jadro P270, ktere poskytuje vektorove rozsireni. Toto jadro je hodne malicke. (dual-issue, in-order, cili asi jako Cortex A53 nebo stare in-order Atomy). Vtip je v tom, ze je male a ze jich na danou kremikovou plochu muze SiFive naplacat hodne a navic je mozne ho kombinovat s vykonejsimy jadry. Takze zatimco P550/P650 bude plnit funkci velkeho jadra, tak P270 plni funkci maleho jadra. Narozdil od Intelu, kde avx512 jedou na velkych (resp. mohou jet!), ale ne na malych jadrech, tady vektory pojedou na tech malych a ne na tech velkych. Stejne jako u Intelu se zde jedna o zamerne zjednoduseni, tak aby OoO jadra byla mensi, levnejsi a uspornejsi. Coz prave SiFive vyzvedava ve svych marketingovych vystupech v porovnani s ARM.
No jestli tvrdí, že je to schválně a strategie, tak bych tomu moc nevěřil.
To pak má stejný problém jako Alder Lake, kdy big a little mají odlišnou ISA a ve výsledku se nic, co má jen jedno z jader nedá normálně použít. V případě ALder Lake ale nepřijde člověk o všechno SIMD, ale jenom o část, i s tím "jenom" AVX2 to zůstává hodně schopné. Kdyby se nedalo na všech jádrech použít ani AVX* nebo dokonce ani SSE*, tak to ale úplně vyhoří.
Podle mě to není reálně schůdná cesta, protože SIMD instrukce nejsou jako akcelerace na GPGPU nebo na koprocesoru. Můžou sice mít podobnou roli, ale jsou i k tomu, aby se s nimi dala lokálně zrychlit jakákoliv funkce kdekoliv v programu nebo ovladači i OS. Třeba i memcpy/memset, parsování řetězců/XML, programátoři pro ně najdou všemožná uplatnění. A tyhle funkce nesmí mít postih v latenci z toho, že se nejdřív musí přesunout na koprocesor, GPU nebo jiné jádro a pak zpět, jinak snaha o takové zrychlení nemá smysl.
Například chcete, aby k nim měl přístup javascript engine, webový prohlížeč, nebo jiná úloha u které chcete maximální single-thread výkon (a tedy aby běžela na velkém jádru).
No, jedna vec je, ze si Jan Olsan mysli, ze to neni schudna cesta. A druha vec je, ze lidi ze SiFive si mysli, ze je. Pripomenuti: na SiFive RV64 *NEJEDOU* Windows, takze namete stejne problemy jako u ADL. Ten Linux co je dneska de-facto standardem na tech masinach se da ohnout ledacjak. Treba tak, ze v ELF binaru mam zapsany extenze CPU, ktere binara potrebuje a pak uz cela aplikacka bezi na jadru, ktere ho podporuje. A nebo tak, ze bezim na OoO a kdyz vyvolam vector isn, tak to hodi vyjimku. Vezmu cely kontext procesu, narvu ho na P270, vratim se o instrukci zpet a execnu znovu. Chapejte, mam zdrojaky k cele platforme a necekam na velky byrokraticky moloch M$ kdy mi hackne scheduler aby to ADL jelo jak ma.
Ano, souhlasim si tim, ze je to neco cemu se rika "trade off". Mensi/mene zrava jadra OoO za prudu pri vektorech. Taky nikdo nerika, ze to tak bude naveky veku. Ted mluvime o 7nm/Intel 4, az to pujde na nizsi nody a SiFive to posune dal, pak budou vectory i na OoO.
To ale není problém jenom na Windows a to, že je dsitribuce softwaru ve formě zdrojáku a všechno se tedy stejně kompiluje znovu, to IMHO ten problém moc neotupuje. Uživatelé a/nebo programátoři to budou nést nelibě všude.
IMHO by to bylo akceptovatelné v embedded (jak jsem psal v článku) a podobných aplikacích, ale tam spíš místo těch malých SIMD jader budou přidané speciální akcelerátory uzpůsobené pro ty konkrétní úlohy. Jako příklad mě napadl třeba řadič SSD....
Je to ale názor, plést se v tom samozřejmě můžu.
Že je to přechodné, to si myslím rozhodně také. Jak tam píšu, vektorovou jednotku to P550/P650 nemá nejspíš proto, že ji ještě nemají připravenou (a to je nejspíš kvůli stavu standardizace, ne že by jim dělalo problémy ji vyvinout). Proto to to taky nejsem ochotný vnímat jako záměrnou strategii, protože až tam ta jednotka SIMD bude, tak si všichni oddechnou a zpět se nikdo vracet chtít nebude* (zase IMHO).
* i když možná bude nějaká verze podobného jádra bez FPU/SIMD pro potřeby té integrace do řadičů a pod.