O jakem cell blockingu melete?
A programovani CELL procesoru neni takovej orisek... architektonicky to je v podstate pouze DSP jako kazde jine (at uz to srovnavame s nabidkou ADI nebo TI), pripadne pro mladsi generaci - je to SM z gpu, pribastlenej k CPU, takze odpada uzke hrdlo a vysoke latence rountripu v podobe PCIe - je to spis jako mit ty GPU SM v druhem socketu.
Problemem jsou aplikace - na takove architekture nemuzete provozovat obycejny kod - stejne jako ze na graficke si nepustite windowsy - no nebylo by to skvely si je tam pustit, kdyz mate k dispozici deset tisic jader? :D
Takze z vyhajpovaneho luxusu se dostavame na to, co to bylo - vektorove jednotky, vyzadujici explicitni obsluhu. Coz nam moc nepomuze - kdyz je nemame cim krmit. I pro sebelepsi desktop/server pouziti, si prakticke vyuziti dokazu predstavit jen jako codec DSP - ze to bude dekodovat a enkodovat treba jpegy. Proste takovy lepsi MMX.. ktery je vam taky v bezne zatezi k nicemu.
Kdyz se podivate kde jinde se tyto cpu pouzivali, tak tam to uz dava vetsi smysl - to uz jsou typicke DSP zateze.
Problem s je v tom, ze veskerej vyvoj se dela na PC. A ono se dost blbe dela neco pro uplne jinou architekturu nez na ktery to prgas.
Sekundarne tu jsou pak samozrejme opakovane zkusenosti na tema ze ty se to naucis, a vyrobce to zrusi. Treba zrovna stema widlema vs non x86. Zadnou aplikaci pro win a treba arm nikdo delat nebude, protoze vsichni vedi, ze za rok zadny arm win nebudou ...
A vyvoj na jine architekture vadi cemu prosim? I pro druhy nejvetsi system schopen provozu plnotucneho OS (arm/arm64) se vyviji primarne na PC skrze cross-compilaci, jak u embedded, tak u arm-win, tak u HPC. A u RiscV to same.
Pouze Apple silicon ma nativni Xcode, pro vyvoj v ramci sveho ekosystemu (a tam se zas cross-compiluje pro x64).
Reknete nam, jak je vyvoj pomalejsi?
V pripade optimalizace na x64, muzete pouzit intel loop analyzer, ktery vam napise ktere porty a jake uops jsou pouzity na dane mikroarchitekture.
V pripade cizi platformy - mate od vyrobce znova simulacni modely, kdyz potrebujete odladit neco, na cem zalezi. A pak existuji i fyzicke demo platformy / vyvojove kity, na kterych si to muzete ozkouset v sirsim kontextu.
Nic tezkeho to neni - bud dany job umite zvladnout, nebo jste neschopa, ktery nema ve vyvoji co hledat.. a ze tech darmozroutu je ve studiich docela dost (a u korporatu jeste vice).
Takze ne - nemuze za to (slozitost a atypicnost) platformy. Je to stroj. Pokud to se strojem neumite, tak to nedelejte.
To se pouziva i kdyz vyvijite na te same platforme. Predstava, ze si vyvojar pusti na sve dev masine cilovej kod je docela zcestna.
I pri zakladnim vyvoji treba ovladacu jsme vzdy pouzivali separatni stroj, treba bootavny ze site, aby nam nejaky kernel panic neodrovnal debugovaci stroj.
Tohle nema nic spolecneho s tim, zda je architektura stejna nebo jina. Krome architektury totiz hraje roli i operacni system, a ten stejny na konzolich neni ani nahodou. Vzdy tam bude potreba nejakeho fyzickeho rigu i kdyz je to x64.
Tys nekdy napsal aspon hello world? Nevypada to ... japa budes asi cokoli testovat ... jo aha, prekompilujes to, a pak budes resit, ze to nejde spustit, ale ani debugovat ...
A arm je toho zarnym prikladem ... jakej ze je pomer aplikaci vuci x86? 1 ku milionu? Asi tak nejak ze? Proc asi ... A procpak soudruzu pouzivaji treba javu ... zeby presne proto? Jo, hra se v jave taky da napsat ... minecraft. A presne podle toho to vypada i funguje. Srv pro 100 lidi za mega stacit nebude.
Nechápu ty narážky na ARM. Není už většina aplikací pro něj zkompilovaná? Vždyť výchozí režim ve VS už je "ať to funguje jako na x86, včetně možnosti loadovat x86 DLL". "Nativní" ARM je pak až pro fajnšmejkry. Kamarád vývojář má po letech už všechny aplikace nativní.
28. 3. 2025, 17:14 editováno autorem komentáře