Vlákno názorů k článku Superpočítač z Raspberry Pi bude mít až 40 000 jader od RDa - "přičemž proporčně má Raspberry Pi adekvátní výkon CPU,...
-
"přičemž proporčně má Raspberry Pi adekvátní výkon CPU, velikost RAM a propustnost síťového rozhraní tomu, co odpovídá budoucím superpočítačům, podobně jako malý model architekta odpovídá budoucí velké budově."
Tohle je dobrý blábol. Ono snad bude tisíc 16 MHz mikrokontrolérů odpovídat osmijádru na 2 GHz? Ani náhodou. Superpočítače mají propoje mezi uzlama na úrovni 40 Gbit ( 10G u předešlé, 100G u nadcházející generace) s podporou RDMA (tj. Infiniband nebo modernejší converged ethernet), RPi má jenom USB a i 100 Mbit síť implementuje stylem análního zubaře, o přímém DMA a nízké latenci si může jenom zdát.
Z RPi tedy postavíte cluster, nebo masivní cluster když máte peníze, to jo, ale nebude to ani náhodou superpočítač. Chybí tomu ono dedikované sdílení paměti a typ řešitelných úloh je tedy zcela odlišný.
-
hepterida (neregistrovaný)
Máš určitě pravdu a díky za tohle doplnění. Z článku jsem si vzal to, že je to alespoň nějaká možnost, jak do jisté míry simulovat chování superpočítače. S limity, které maliny mají (včetně propojení a sharování paměti). Na druhou stranu, pokud po tomhle typu use casů bude poptávka, dokážu si představit HW úpravy Raspberry s podporou rychlejších sběrnic. Bude to sice dražší, takže nákup půjde z grantů pro školy, ale stále levnější, než čistokrevné superpočítače.
-
Bubo (neregistrovaný)
Ale ved o to vobec nejde!! Ja som to pochopil tak, ze hoci je takyto "superpocitac" hrozne pomaly, tak dolezite je, ze fyzicky existuje. Ze sa na nom da otestovat software kedykolvek a skor ako za strasne prachy pobezi na skutocnom superpocitaci. A s tou spotrebou to tiez nebude take zle. Ta je na urovni jednotiek KW.
-
VLM (neregistrovaný)
Ladit nějaký SW (clustry, mnohojádrové paralelní zpracování atd.) na něčem co polyká MW příkonu o ceně strojového času ani nemluvě asi nebude to optimální. Takhle budou mít obrovské množství procesoru s náklady o několik řádů nižšími, výkon/rychlost na vyřešení velké řady problémů asi nebude to důležité.
-
mhi (neregistrovaný)
Udelat sdilenou pamet mezi procesory sice zni jednoduse, ale ve finale to je docela slozita vec, na uplne jine urovni nez zbastlit hromadu ARMu dohromady pres nejake USBcko. Vykon nejakeho nadupaneho x86 to hrave smete.
Mozna by bylo ale zajimave vzit nejake FPGA se SERDES moduly a nacpat to primo na sbernici ARMu a udelat tam chytry message passing. Na tech armech by k tomu mohlo teoreticky jit pouzit i HDMI rozhrani (netusim ale jestli se da na Bradcomech do takove miry "znasilnit" aby posilalo co chci ja a ne obrazky :-) ). U nejakeho mediateku to bylo tak volitelne programovatelne, ze by s tim zrejme sel implementovat i sitovy adapter. vlastne to byl takovy hodne chytry SERDES s DMA.
-
My nad timto uz uvazovali - u teto kategorie procesoru by slo vyuzit DSI a CSI rozhrani (vystup na displej a vstup na kameru). Oboji ma stejnou fyzickou vrstvu takze spojit dva k sobe by problem byt nemel. Horsi je to se synchronizaci - jsou to kanaly ktere (az na vyjimky) jedou plnou rychlosti (posilaji se proste snimky, jeden za druhym) takze si to pak musite proparsovat a najit si sve pakety dat ktere jste chtel vykomunikovat. Mensi problem je, ze kamera i displej pouziva jine synchronizacni hlavicky a neni jiste zda lze jedno z tech rozhrani donutit vysilat nebo akceptovat jinou hlavicku.
Pro vetsi systemy by jste interconnect museli realizovat bud ciste pres vlastni FPGA sit, nebo konvertovat tyhle jednosmerne CSI a DSI porty na nejake jine rozhrani ktere se pak da switchovat klasickymy obvody (Infiniband, Ethernet). Zde by z RPi CM3 melo jit vytahnout zhruba 5Gbit v kazdem smeru.
Samozrejme i v ARM procesorech existuji rozhrani, pres ktere se da komunikovat. Bud to je velice standardni PCIe v tech vetsich procesorech, nebo pak specializovany nizkoprikonove - TI C2C nebo MIPI LLI, ale tyto jsou znova jen na spojeni dvou komponent (napr. SoC s modemem, ktery pak nemusi mit vlastni pamet).
-
mhi (neregistrovaný)
Ono to je o volbe vhodneho SoC/MPU. Ten Mediatek mi tehdy prisel jako velmi zajimavy, byla-li by k nemu nejaka dokumentace. Patlal jsem se s reverse engineeringem neceho az jsem prisel na to, ze ten modul je vymyslen velmi obecne a ta hejna konstant co se cpou do ruznych kryptickych registru proste nastavuji casovani, co, odkud, kam posilat.
Treba radiova cast tam je resena pres nejake DSP (tusim TEAKLite v jedne verzi) a slo se tomu docela slusne vrtat v dualportove RAM, navic tam byla fce patchrom. To by davalo obrovske moznosti pro zpracovani libovolneho RF signalu. Ale opet: nulova dokumentace.
K tem velkym clusterum by mohla byt zajimava jeste kombinace ARM+lowcost FPGA jako koprocesor na nejake podulohy. Zde je ale opet problem v tom, ze maloktery ARM SoC umoznuje pripojit nejake externi komponenty na rychle sbernici, vetsinou to ma silenou latenci. Takze napr. na spocitani nejakeho sifrovani ve forme "koprocesorove instrukce" to je naprosto nepouzitelne.
Na toto se spis hodi nejaky tupy 16bit, ktery ma I/O piny stejne rychle jako MCU (typicky PIC24, dsPIC33 to tak maji a presne takhle formou hazeni bitu sem-tam do FPGA jsem si neco takoveho implementoval). Bohuzel na tom zase nebezi zadny smysluplny OS, nema to MMU, neni to rozsiritelne o pamet ...
-
Tak primo ukazkovy priklad toho co by jste asi potreboval je ARM+FPGA = Xilinx Zynq, pripadne alternativa od Altery (Intelu) - Cyclone V SOC. Tam si muzete udelat paralelni co-processing mezi ARM kodem a FPGA strukturou - nad stejnou sdilenou pameti (bud FPGA saha do pameti ktera je u CPU, nebo CPU saha do pameti kterou pripojuje FPGA). Na urovni implementace instrukci to neni, spis komunikace skrz registry, preruseni a te sdilene pameti.
-
mhi (neregistrovaný)
No jo, ale ta cena... za Zynq :-).
Prijde mi efektivnejsi koupit ARM za $2 a k tomu nejake lowcost FPGA urcene do mobilu za dalsich par jednotek USD. Samozrejme zalezi na uloze, vetsinou automat do FPGA je velmi maly a vyuziti velkych FPGA mi neprijde adekvatni ucelu. Mozna to je ale tim, ze s nimi neumim delat.
-
mhi (neregistrovaný)
Zynq stoji podobnou castku jako kdyz se vedle sebe nasklada stejny pocet LUTtu z malych ICE40. Nezkoumal jsem detaily, treba jak je LUT organizovany. Souhlasim, ze samotny Zynq je vykonnejsi, ale kombinace nejaky lowcost ARM+FPGA pro urcite ulohy je mnohem levnejsi.
Mimochodem, na Lattice mne zaujalo, ze jejich nastroje dokazaly narvat verilog do LC4032, ktery se uz nevesel zadnou cestou do XC9536. A to jsem to nedelal ani pres Synplicity. To by mne zajimalo, kde Xilinx udelal "chybu".
-
mhi (neregistrovaný)
Jo... to jsem u Xilinxe zazil taky. Odebrani signalu zpusobilo, ze se to nefitnulo. A jednou pomohlo k fitnuti presunout hodiny z I/O pro to urceneho nekam jinam.
Ten Lattice me ale opravdu zaujal, aktualne jsem resil migraci z Xilinxe (XC9536XL-jednoduchy automat) a nedaval jsem tomu sanci aby se to do te 32ky naroutovalo, CoolRunner 32 to taky nedaval. Xilinx byl prave v tom stavu ze se na kod nesmelo zadnym zpusobem sahnout. Latticovi je dokonce vcelku jedno kam mu strcim jaky signal. Realne to jeste overene nemam, deska neni vyrobena, ale ze by ispLEVER takhle moc kecal se mi nechce zdat :-).
-
Petr M (neregistrovaný)
Někdy je dokonce levnější nějaký jednočip jako I/O koprocesor pro real time... Je to aplikaci od aplikace. Pokud jde o propojení několika SoC na jedné desce, tak se zatím jako nejlepší jeví MII. Ale tím nějak RPi nedisponuje... :( Fakticky tohle a chybějící SATA na RPi bolí nejvíc
Nebude to tím, že Lattice má víc p-termů na výstupní buňce? Xilinx dá víc buněk (36 vs 32, 72 vs 64), ale pokud je míň funkcí víc proměnných, Mach4k je lepší volba.
-
mhi (neregistrovaný)
Nevim, logiky je v tom verilogu docela dost.
Ja se k tomu LC4000 dostal vlastne tak, ze jsem chtel nejakou levnejsi nahradu za XC pro pripad, ze ty nebudou snadno dostupne (XLX se snad za radu XC95xxXL stydi, neni ani na webu, atd., tak cekam kdy prijde EOL notice, navic zdrazili za 3 roky o 50%).
-
Petr M (neregistrovaný)
Tak ono je to hlavně CPLD, ne FPGA. A za CPLD se výrobci obecně stydí (Altera místo toho má pidi FPGA MAXII, Actel taky CPLD nemá a posledně místo toho nabízeli Igloo,... ). I u Lattice tlačili XOčka (teď XO2) a LC4000 mimo provedení ZC už se taky blbě shání... :( Přitom na kombinační logiku jsou CPLD nepřekonatelný.
A při tom Lattice furt prodává prapradědečky GAL... :(
Další věc je, že XLX si začíná hrát na drsňáky s hi-tech a exportním omezením, takže třeba co jsem zaslechl, tak Asix jako distributor skončil když chtěli potvrzení, že ty součástky neprodají na vojenský materiál atd.
-
mhi (neregistrovaný)
Ja vim, snad vsichni tlaci FPGA misto CPLD. Predpokladam, ze asi vi co delaji a trh to chce (jestli ICE40UL se prodava po milionech denne do mobilu, tak to docela i chapu, ale roztece WCSP16/BGA36 pouzdra dost komplikuji pouziti.
Nicmene je tu spousta legacy aplikaci a spousta aplikaci kam se hodi to "historicke" CPLD (ci GAL) a neni k nemu ani cenovy FPGA ekvivalent, nepocitam ruzne napajeci napeti a jine slozitosti co se s tim vezou. Pak mi prijde prapodivne, ze treba DigiKey stockuje nejvic XC95xxXL ze vsech CPLD a XLX to ani nemaji na webu.
My objednavame i vetsi veci ze statu (tech Xilinxu ted' bylo 6500 ks) a DigiKey nam to prodal bez nejmensiho problemu (ano, chteli vypapirovat k cemu to je, ale moc neprudili).
-
Petr M (neregistrovaný)
Tak jasně, nenasimuluje se HW, ale na úrovni TCP/IP je jedno, jestli tam je 100G optika nebo 100M Cu.
Pokud jde o to zkusit rozhodit výpočet na 50 strojů (rozdělení úlohy), může být bedna plná RPi dobrý trenažér.
Pokud jde o management a update několika set desek naprosto identicky, tak je lepší 100x RPi za dva litry, než 100x plnohodnotný PC za deset, nehledě na prostor a spotřebu... -
Ivan Nový (neregistrovaný)
Ono se pak ukáže, že k nejvyšším časovým ztrátám dochází díky přesunům informací mezi uzly a rychlost zpracování závisí hlavně na vhodném algoritmu jejich distribuce, nikoliv na samotném výpočtu realizovaném na daném uzlu.
Je otázka, zda by to nešlo nasimulovat klasickými prostředky bez nutnosti fyzické realizace zkušebního prostředí.
-
aaaa (neregistrovaný)
To nie je o vykone, takze 1000x16MHz spojenych cez 10Mbit siet sa bude pri testoch paralelnych algoritmov chovat viac ako 1000x2GHz spojenych cez 100Gbit siet, ale uplne inak ako 8x2GHz. S latenciou na testy plati, ze vacsia pomaha optimalizaciam pre sirsie nasadenie.
Zdielanie pamati je problem, to ma uplne ine chovanie.
-
dustin (neregistrovaný)
Pustil sis to video? Vůbec nejde o celkový výkon, ale o levnou aproximaci reálného clusteru, na které mohou vyvíjet software pro správu, bootování, monitoring velkých (= drahých, žravých a permanentně vytížených clusterů). Díky relativně podobným poměrům výkonu/paměti/sítě se to pro tyto účely chová velice podobně.
-
lazywriter (neregistrovaný)
Navíc, to lze v prostředí, kde jsou k dispozici solvery pro dvě dost odlišné architektury. V případě komerčních solverů trvá roky, než jsou implementovány změny v jedné architektuře (např. při rozšíření instrukční sady). Např. akcelerace na GPU většina z nich pořád ještě neumí a už vůbec není reálné, že by dodavatelé podporovali ještě ARM.
-
ded.kenedy (neregistrovaný)
"přičemž proporčně má Raspberry Pi adekvátní výkon CPU, velikost RAM a propustnost síťového rozhraní tomu, co odpovídá budoucím superpočítačům, podobně jako malý model architekta odpovídá budoucí velké budově."
Tohle je dobrý blábol. Ono snad bude tisíc 16 MHz mikrokontrolérů odpovídat osmijádru na 2 GHz? Ani náhodou. Superpočítače mají propoje mezi uzlama na úrovni 40 Gbit ( 10G u předešlé, 100G u nadcházející generace)
Sam jsi blabol. Dulezite je to slovo proporcne. To znamena, ze ten pidi cluster bude mi procesory treba desetkrat pomalejsi nez skutecny cluster, bude mit soucasne desekrat mensi pamet a k tomu bude mit dejme tomu desetkrat pomalejsi propoje. Ma to slouzit jako model, na kterem si budou moci vyzkouset a odladit system.
-
Sinuhet (neregistrovaný)
Jedna z mých největších záhad. Přehrady a stébla trávy. Když příroda zvládne udělat 2 metry vysoký výtah na vodu o průměru 2 mm (a ještě dutý), proč by člověk nemohl postavit takový mrakodrap?
Ono s těmi měřítky je to ošemetné :-D zase na druhou stranu velký hráz se rozpadá mnohem pomaleji než její model.
-
Pavel (neregistrovaný)
Protože s rostoucí velikostí roste průřez stébla s druhou mocninou rozměru a jeho hmotnost s třetí mocninou. Takže s rostoucí velikostí musíte na stéblo použít materiál, jehož pevnost roste úměrně rozměru toho stébla.
Koneckonců na toto přišla příroda samozřejmě už dávno. Proč jsou asi kosti myší tak tenké, že skoro nejsou vidět, ale kosti slona jsou v poměru k délce neskonale silnější?
Samozřejmě, pokud se testují modely v měřítku, tak se tomuto měřítku musí přizpůsobit i to ostatní - třeba pro modely hrází se používají místo vody tekutiny s vyšší hustotou a viskozitou, atd.
