Vlákno názorů k článku
Compute Blade: server z Raspberry Pi Compute Module do serverové skříně od dustin - Přemýšlím, k čemu by to bylo dobré. CM4...

Jedna se o “produkcni” aplikaci. Mam stesti ze se to da provozovat prakticky na cemkoliv (nejake pozadavky na minimalni ram). Vykon jednoho jadra neni podstatny. V soucasne dobe jsou tam stovky cores (ruznych), do budoucna se pocita s vyssim poctem cores a cena za core je zajimava.

Asi stejně jako ostatní stále nechápu, jaký je příklad použití, kdy je lepší mít třeba čtyři pomalá jádra, než za stejnou cenu jendo jádro, které ale za stejnou dobu spočítá desetkrát víc, než ta čtyři jádra. Vypadá to jako situace, kde by byl problém, pokud by se o jedno rychlejší jádro střídalo více úloh, a vyplatí se úlohu provozovat na pomalejším jádru, ale bez střídání – a pořád si nedovedu představit, jaký typ úlohy by to mohl být.

Možná v situaci, kdy potřebuje skutečně ARM - distribuce pro ARM se prý necrosskompilují. No a výkonný ARM za rozumnou cenu nekoupí.

Tomu reseni je fuk jestli je to arm, intel nebo amd, ono by to mozna bezelo i na mikrovlnce kdyby mela dostatek ram.

Ale crosskompiluju, ARMy su casto v zariadeniach na ktorych nemate sancu nejako moc kompilovat. Napr. zgemma H9 ma Hisilicon Hi3798mv200 a asi nikoho nenapadne kompilovat pre nu enigmu2(tv/sat linuxove distro) inak ako pod linuxom na x86 architekture.

Podivejte se na to z pohledu ceny, za $11k mam 64core amd, za $1k mam xx desek se stejnym poctem cores. Za usetrenych $10k muzu mit dalsich 600 cores. Ty jadra nebudou tak vykonna jako jadra toho epycu ale celkovy vykon pro danou aplikaci je proste vyssi.

Vy pořád uvádíte počet jader, ale neuvádíte žádný typ zátěže, kde by záleželo na počtu jader a ne na jejich výkonu. U běžných programů je podstatný počet jader krát jejich výkon. Mne by právě zajímalo, co je to za typ aplikace, že by vadilo, že třeba 4 úlohy, které se počítají na 4 pomalých jádrech 1 sekundu, budou seřazené za sebe a jedno rychlejší jádro je vypočítá za 0,6 sekundy (tj. výsledek budete mít dřív, i když ty úlohy budou seřazené za sebe na jendom jádru).

Filipe, rychle jadro bude pocitat ulohy rychlejc ale za vyssi cenu. A o naklady tady jde, proc platit $11k za neco co muzu mit za $1k. Aplikaci je jedno jestli jestli ji spustim na 10x128cores nebo na 500x2 core.

Právě že u běžných aplikací to bude počítat úlohy za nižší cenu. Protože vám na stejnou práci bude stačit menší počet jader. Když je jádro šestkrát rychlejší, spočítáte na něm třeba pětkrát tolik, než na pomalém jádru. Když bude stát třikrát víc, než pomalé jádro, spočítáte toho za stejnou cenu víc na tom rychlém jádru než na třech pomalých.

Jsem jenom zvědavý, zajímal by mne ten typ aplikace, kde nezáleží na výkonu jader. Dovedu si představit, že je to nějaká realtime obsluha, kde by nějaký signál musel mít své vlastní vyhrazené jádro, protože by nebylo možné čekat byť jen pár taktů procesoru, než na něj přijde řada. Ale to mi zase nejde dohromady s RPi a jejich nastrkáním do jendé skříně.

Dobrý deň,
zapojím sa do úvahy... Viem si predstaviť aplikáciu napísanú tak, že spúšťa jedno vlákno pre jednu úlohu (nepoužíva epoll) a pri spracovaní robí I/O z pomalého zdroju. Napríklad po sieti odchytáva každý miliontý paket a potom nad ním robí chvíľku...

Druhý príklad z praxe (kde je dôležitejšia cache, ako čokoľvek iné). Aplikácia si drží objem nastávkovaných peňazí (náber) na jednotlivé stávky (vyhrá Slovan, vyhrá Menčester, Prvé podanie Džokoviča skončí v sieti, ....). Teda potrebuje potenciálne milióny, až miliardy, hodnôt. Následne potrebuje čím skôr vedieť povedať, či na niektorú stávku neprekročil novopodávaný tiket nejaký limit. Teda zoberie sa nový tiket a jeho stávky a pripočítajú k jednotlivým náberom a kontrolujú sa stropy (pri tenise nie viac ako 10k€ na náber, pri futbale nie viac ako 25k€, ...). Toto musí byť rychlé, minimálne ako potočenie rulety z end2end pohľadu. Tuná je vpodstate fajn mať veľkú cache (aby tam vošli všetky nábery). Osobne mám ale pocit, že stále výde jeden serverový x86 CPU lepšie, ako kpec nevýkonných armov.

lubo: V Linuxu ale vlákno programu není totožné s vláknem/jádrem procesoru. Linux má preemptivní multitasking, což znamená, že operační systém přiřadí vykonání nějakého softwarového vlákna na jádro procesoru, a po nějaké době zase jádro procesoru softwarovému vláknu odebere (vykonání softwarového vlákna přeruší). Takže v systému může být násobně více „běžících“ softwraových vláken, než kolik je skutečných jader procesoru. Tím, že se softwarová vlákna v běhu velmi rychle střídají to vytváří iluzi, že běží všechna najednou.

O tomto povedomie mam. Preto spominam cache. Ono ked v cache nieco mam, tak pristup k danej informacii trva radovo nanosekundy... Akonahle mi to ale niekto z cache vyhodi, tak som o rad az dva inde s casom pristupu. Ci sa mi medzitym spusti iny proces, alebo nie, je vpodstate takmer jedno (zo statistickeho pohladu, bo contex switch je tiez drahy).

Ja len, ze cache by mohla byt dovod, preco cloveku nezalezi na vykone/takte procesora, ale na ich pocte. Na druhej strane, ten Rpi CM4 ma procak BCM2711 a ten ma uvedene: Caches: 32kB data + 48kB instruction L1 cache per core. 1MB L2 cache. Teda pri 4 jadrach to je zaokruhlene 1MB L2 cache. Akykolvek xeon bude mat 8MB cache (nejaky model z 2017), takze aj v tomto smere nie je vidno zmysel "radsej viac jadier, ako rychle jadro".

Kam som smeroval s tym preemptivnym multitaskingom: SKuste si nasimulovat 1000 android telefonov stahujucich jeden subor cez http protokol a simulujte im linku napriklad 2kbps. Spravte to s vlaknami a dajte vediet, ako to bude bezat na xeone a ako na klastri 1000 kusov Intel 8086 cpu. Sem smerujem, ze tu by mozno dane tvrdenie "radsej viac jadier, ako rychle jadra" mohlo mat zmysel. Teda pri vysoko neefektivnej architekture riesenia problemu.

PS: Na mojom notasi som sa k viac ako 2700 beziacich klientov nedostal... (minimalisticky C kod) Ale pritom jednoduchy javovy kod vyuzivajuci epoll zvladol 100000 beziacich klientov a ani sa nezapotil (samozrejme, vyuzival len jedno vlakno).

12. 2. 2023, 20:29 editováno autorem komentáře

lubo: Pokud myslíte cache procesoru, tam se nevejdou miliony nebo miliardy hodnot. Navíc v tom vašem příkladu byste nejvíc času strávil na výběru toho správného vlákna, kterého se daný případ týká.

Ale směřujete k tomu, co jsem psal – zátěž, která potřebuje okamžitou reakci procesoru, takže nemůže čekat, až bude naplánována na procesor. Jenže to vyžaduje realtimeový operační systém – a pokud by na to nestačil realtime linux na platformě amd64, nezachrání to RPi. A už vůbec ne RPi v clusteru, protože komunikace mezi uzly bude o několik řádů pomalejší, než plánování na jendom procesoru.

U té simulace souběžných spojení bych tipoval, že vyjde levněji jeden pořádný stroj než ta řada RPi. Nemluvě o tom, že je jednodušší to naprogramovat pořádně pomocí epoll než ten naivní kód složitě distribuovat do clusteru.

Každopádně já určitě netvrdím, že neexistuje případ, kdy by to dávalo smysl – věřím, že Ratbatcat ví, proč to tak dělá. Jen bych to chtěl pochopit, abych se poučil.

Napadá mě GPIO, ale nevím, jestli je to dostatečný argument. Lze najít i nějaké GPIO do USB, otázka je latence. Možná i do PCIe, to by asi nebylo horší než RPi (hádám od stolu). A pak nějaké hotové HATy, ale to mi přijde dost specifické, aby se na to vyplatilo vyvíjet podobné řešení…

Filipe, rychle jadro bude pocitat ulohy rychlejc ale za vyssi cenu. A o naklady tady jde, proc platit $11k za neco co muzu mit za $1k. Aplikaci je jedno jestli jestli ji spustim na 10x128cores nebo na 500x2 core.

Já to ale taky nechápu. Obhajuješ tady řešení, ale přitom sdílíš jen jednu konstantu.

Minimální informace ale jsou CPU+RAM+konek­tivita+vytíže­ní, a dále provozní náklady za měsíc/rok, včetně toho, že některé to RPI se občas posere a je potřeba ho nahradit == extra čas + peníze.

Tím nechci říct, že tvoje řešení je špatné, ale bez kalkulace a minimálně srovnání s něčím jiným je to neobhajitelné, protože většinou platí, že čím lepší technologie (čti litografie), tím lepší provozní náklady, které jsou mnohdy důležitější než pořizovací cena HW. A RPI na 22nm není efektivní, v podstatě minimálně 4x pomalejší než starší X86 CPU. U moderního X86 jádra to bude někde kolem 6x.

Kdybych počítal, že jedno moderní jádro je 6x rychlejší než jedno RPI jádro, tak jeden AMD Ryzen 7950X by nahradil asi 48xRPI4 a potřeboval by 64GB RAM, aby měl 2GB / 1 thread (tak jako RPI4B 8GB). Jedno RPI4B 8GB se dá koupit v ČR za ~100$, takže 48 RPI by stálo 4.800$ a mělo by spotřebu 6W*48 == ~290W - naproti tomu ten Ryzen by se dal nastavit do ECO módu 65/100W.

Naprosto jednoduchá kalkulace, která zohledňuje v podstatě jen ten CPU výkon. Schválně jsem vybral jen levný desktop CPU, protože RPI taky není nijak certifikovaný pro server použití a taky nemá ECC RAM.

Pro informaci RPi4 má v "openssl speed rsa4096" v jednom vlákně 29.8/2284 a ve čtyřech 119/9107.

Ryzen 9 5950X (16core 32thread) má v jednom 173/11681 a ve 32 2405/201255.

Takže jednovláknově je v tomto (nereprezenta­tivním) testu 5.5x rychlejší (takže ten novější Ryzen bude 6x jak píšeš), a celý procesor nahradí 21 Raspberry, nikoli 48 jak píšeš, protože sis asi popletl thread a core, zas tolik tomu „hyperthreading“ nepomáhá.

Ale ten komp s Ryzenem IMHO fakt stál a žere trochu méně než 21 RPi + bych k nim musel řešit napájení, pospojování, SD karty, management… (zase je to trochu víc redundantní, i když jednotlivé nody budou nespolehlivé).

Ale překvapilo mě, že ten rozdíl není řádový, ale jenom několika málo násobný! Na první pokus bych tipoval že to bude klidně 10x, ne ~2x!

12. 2. 2023, 21:40 editováno autorem komentáře

Ten vypocetni vykon vychazi trochu jinak. Elektrina je tady levna (bydlim v US), prostor nikdo neresi, a ano, manazment toho celeho mixu ruznych zarizeni byl potencionalni problem, do chvile nez jsme ho proste prestali resit. Novy stroj se zapoji, kazdy z tech stroju ma svuj image ve kterem je uplny prd, dostane to adresu z dhcp a instalacni skript z image nainstaluje aplikaci a ta pak bezi. Pokud to umre tak u ceny $50 za kus nikdo neresi proc to umrelo, proste se to nahradi jinym strojem. Ani u ceny $200 se neoplati delat jakykoliv troubleshooting. Za rok “odejdou” stroje za par tisic. Nikoho u tohodle nezajima ecc ram nebo eko mod, kazdy z tech stroju zpracuje nejakou operaci ve ktere jsou nejake pomale I/O, jsou tam nejake mezioperace na zpracovani kterych je ten stroj zavisly a pak to nekam posle vysledek. Kazdy z tech stroju zpracovava paralelne xx operaci. Jak tady nekdo spravne poznamenal, ty cisla u tisicu procesu vychazeji trochu jinak. Jak jsem psal zkouseli jsme tomu naivne dat nejlepsi ryzen na trhu a vykon ve srovnani s 10core intel nenaplnil ocekavani, proto jsme zkusili jit cestou vicero stroju s nejakym minimem zdroju. Ta aplikace samozrejme neni napsana optimalne, ale znate to… Jestli je tohle dlouhodobe reseni netusim, zatim to dela to co ma a generuje to zisk. Porad ale zkousime novy/jiny hw a dle nejakych benchmarku budto kupujeme neco noveho nebo ne.
Ja se moc nechci tady rozepisovat o te aplikaci, zaujala me zpravicka o produktu ktery nam treba umozni do budoucna neco resit trochu jinak. Treba.

Dakujem za poodhalenie urcenia. Relativne si to uz viem predstavit a asi by som si vedel predstavit i realne nasadenie, kde by rpi cluster potiahol nejaku firmu riesiacu nakup/predaj akcii a podobne. Teda nie HFT (high frequency trading), ale nejaky sprostredkovatel predaja a nakupu akcii, ktory pouziva dalsich sprostredkovatelov a podla aktualnej ponuky vybera nejaku optimalnu strategiu, ako pre klienta nakupit/predat, co chce.