Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
podle ty tabulky ma el capitan 60 tflops/megawatt a aurora 40 tflops/megawatt.. takze konfigurace el capitan nastavena na stejnou spotrebu by byla 1,5x rychlejsi..
Když to vezmu z jiné strany, tak při posun příkonu z Frontier 27 MW na El Capitan 33 MW by se měl výpočetní výkon zvednou z přibližně 2.0 EFlops na minimálně 2,44 EFlops. To by mělo výkonem minimálně dorovnat, ale spíše překonat Auroru. Přitom spotřeba je téměř poloviční - 33 MW El Capitana proti 60 MW Aurory.
Asi dobrej oddíl. :)
Na Frontieru AMD předvedlo, co umí. 2 EFLOPS za 27 MW je úplně někde jinde než Auroří 2.4 EFLOPS za 60 MW.
Divím se, že DoE už Auroru nezabalilo a nepoptalo AMD, ale asi mají s Intelem nadstandardní vztahy, nebo jsou v tom nějací kapříci...
Prý mají zvyk, pokud je to možné, střídat dodavatele (americké firmy).
Jo, díky tomu má AMD x86 licenci. Jinak by to IBM nenasadilo. Podmínka byla minimálně 2 výrobci.
Ten SW26010 je 4krát jedno velké jádro RISC s blokem 64 malých jader, tedy celkem 260jader na čipu. Je to celkem energeticky efektivní, ale přirozeně záleží na výrobním procesu. Chystají 390jader na čipu, tj. 6x(1+64).
Tady je nejdůležitější, aby ta jádra měla vůbec co počítat. Pokud k tak masivnímu výpočetnímu výkonu není k dispozici adekvátně široká(é) a rychlá(é) paměťová sběrnice (jak pro instrukce, tak pro data) a obrovské cache, tak ta jádra po většinu času budou jen čekat na data z paměti. V principu by v klasické architektuře mělo každé jádro k dispozici jen 1/390 paměťové sběrnice. Paměťová propustnost se ukazuje jako limit i u procesorů s menším počtem jader (64 apod.). O SW26010 toho příliš moc nevím (jen co je na Wikipedii), ale je vidět, že designéři se tímto zjevným problémem důkladně zabývají a mají funkční řešení: NUMA, lokální paměti, více sběrnic, atd.
Samozřejmě velmi záleží na typu úlohy, kterou na tom budou provozovat. Pokud se jim všechna data pro např. numerické výpočty vejdou do cache/lokálního uzlu, tak je to velká výhra.
Že by u většího výkonu mohla být sběrnice a cache brzdou se ví už dlouho. Možná se opakuji ale u RISC / UNIX pracovních stanic a serverů to bylo vidět. Ale bylo to moc drahé a proto trvalo, než se přístup s velkou cache a širokou sběrnicí začal prosazovat v x86 světě. První vlaštovky kdysi byly Pentium Pro.
Promiňte, ale vy jste se do toho obul, přitom říkáte, že o tomto řešení příliš nevíte.
Každé ze zmíněných 256/384malých jader má k dispozici 256kiB lokální paměti, 4/6paměťových sběrnic. Řekl bych, že větší problém tohoto systému je jeho programování, které je snažší u jiných architektur, třeba ty odvozené od Larrabee (Knigts Ferry, Knights Corner, Xeon Phi), ale ty zase mají větší spotřebu, protože mají náročné dekódování instrukcí a paměť typu ccNUMA.
Ta omezení datovou propustností se netýkají jen procesorů, ale i HPC akcelerátorů. Třeba MI200 je z důvodu velmi vysokého výkonu v FP64 omezena i datovou propustností 8192bit × HBM2e. Takže MI300 nebude ani tak posun v hrubém výkonu, jako spíš v efektivitě využitelnosti (velké cache, HBM3).
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.