Processzoronként 24-től 48 magos, kétfoglalatos ARMv8 rendszerek a Cavium Networks-től, openSUSE, Fedora és Java SE 8 támogatás

Bejelentés

Az Egyesült Államokban található Cavium Networks eddig főleg masszívan párhuzamosított MIPS64 processzorok, és azokon alapuló hírközlési, Internet Application Processor, valamint Security Processor csipek készítésével foglalkozott, most azonban az ARMv8 architektúrával is tesznek egy próbát.

A Cavium által ARM licenc birtokában kifejlesztett, 28 nanométer csíkszélességű ThunderX™ processzorcsalád tagjai eleget tesznek az ARMv8 valamint SBSA szabvány előírásainak. Az első gyártásra kerülő típusok a ThunderX_CP™ és a ThunderX_ST™ lesznek, melyek ez év vége felé válnak korlátozott mennyiségben hozzáférhetővé az érdeklődő partnerek számára.

ThunderX_CP™: 48 db 64 bites mag, teljes virtualizáció és logikai particionálhatóság, többcsatornás 10/40 gigabites ethernet, csipenként 4 db DDR3/4 2400 MHz-es, 72 bites memóriavezérlő.

ThunderX_ST™: Az előzőleg ismertetetteken felül kétfoglalatos rendszerek támogatása, többcsatornás SATAv3 vezérlő, 3. generációs PCIe vezérlő, 1TB memória megcímezhetősége kétfoglalatos rendszer esetén, skálázható memória és I/O sávszélesség particionálás a magok között, hardveresen gyorsított adattitkosítás, -tömörítés, -biztonság, és RDMA over Converged Ethernet.

A cég által eddig megkötött terméktámogatási megállapodások:

( hoild | 2014. 06. 25., sze – 11:28 )

A legközhelyesebb infókat majdnem elfelejtettem:
- Maximum 2,5 GHz órajel
- Magonként 78 KB I-cache és 32 KB D-cache
- Csipenként 16 MB, bankonként partícionálható L2 cache

( nevergonealfa | 2014. 06. 25., sze – 14:16 )

Vajon milyen ára lesz egy ilyen eszköznek?
----
FreeBSD, Solaris, Debian, LMDE

( asch v | 2014. 06. 25., sze – 21:58 )

Remélhetőleg ebben nem USB 2.0 mögött van az Ethernet vezérlő :-).

A viccet félretéve nekem a legnagyobb kérdőjelem az, hogy hogyan lehet adattal ellátni ekkora feldolgozó kapacitást? Már egy mag esetén is leggtöbbször a memória sávszélesség a szűk keresztmetszet. Milyen értelmes alkalmazást lehet egy ilyennek találni?

Amúgy meg kéne. Bár kicsit gyanúm, hogy nagyon bugos lesz.

Igy es igy: csipenként 4 db DDR3/4 2400 MHz-es.

Fogadni mernek ra, h dual channel es vegre valakinek eszebe jutott amarra is, h az arm alatti "memoriavezerlok" jelenleg nem letezo fogalmak es csinalt ala egyet vegre. Anno a ket magos Apple A6-nal is komoly szerepet jatszott a 20-30%-kal hatekonyabb memoria kontroller abban, h leverte a korabeli 4 magos Sangsung szarokat alacsonyabb orajelen, mint szuzlany a gyertyatartot az ejjeli szekrenyrol.

---
pontscho / fresh!mindworkz

Ez - mármint a saját memóriavezérlő - lehet-e magyarázat a nagy eltérésekre?

itt: http://a1dev.com/sd-bench/stats/fastest-ram/

Illetve a következő kérdés, telefonok esetén vajon mennyire számít a memória sebessége? Előbb-utóbb új telefont fogok venni, és egyelőre egy dolog volt szempont, hogy sok memória (3G) legyen benne, de lehet hogy a gyorsabb memóriával jobban teljesítene?

Vagy semmit nem számít a szintetikus tesztekkel végzett számháború, alkalmazásokkal kell tesztelni?

A cpu orajeleket elnezve igen, az egy jo magyarazat ra.

Pont a telefonok azok a platformok ahol ez szamit, az azokban levo arm architekturak mar nem lennenek olyan otvar szarok ha nem kell a vasnak kinyulnia a soc-bol. A meret is szamit, de a sebesseg is, kb. egyforman. Persze nem eleg ha az van rairva a csomagolasra, h lddr3, mert ez nem jelenti azt, h ezt ki is tudja hajtani, csak ebbol volt a raktarban elegendo. Es ez minden hardverre igaz, pl. a supermicro xeonos vasainak atlagos memoria busz teljesitmenye az 2.5-3GB/s, a retina mbp-e pedig 6-7GB/s. Ennek oromere egy 12 magos supermicro szerver vegrehajtasi sebessege 16 szazalekos orajel elteressel is fele/harmada egy rmbp-nek annak ellenere, h ebben csak 4 cpu van. (Persze ez igy azert eleg sarkos, mert egyeb parameterek is kozrejatszanak, de a lenyeg lathato.)

---
pontscho / fresh!mindworkz