Az ARM bejelentette az ARMv8 architektúra technikai részleteit

 ( trey | 2011. október 30., vasárnap - 16:27 )

Az ARM néhány nappal ezelőtt technikai részleteket árult el új ARMv8 architektúrájáról. Az ARMv8 lesz az ARM első architektúrája, amely tartalmazni fog 64 bites utasításkészletet. Az ARMv8 az ipari szabvány 32 bites ARM architektúrára épül majd. A bejelentésben olvasható támogató nyilatkozatokból kiderül, hogy a Microsoft, NVIDIA örömmel fogadja majd az új architektúrát.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

sub

már épp ideje volt már.

Még a legelső hozzászólásnak félig begépeltem, de mégsem küldtem el, hogy nem csak a Microsoft és az NVIDIA, de én is üdvözlöm. :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Szólni is kellene az ARM marketingeseknek, hogy ezt hogyan is felejthették el bejelenteni! ;)

Nekik nem szóltam. Elég ha a hupperek tudják! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

like, ize sub

Impressive


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

blokkolnám

Csak en latom ugy, hogy az ARM is kezd egyre inkabb bloatware lenni?
Ugye ott a 32 bites ARM, nagyon jo, szep, egyszeru architektura, az utasitaskeszlete miatt konnyu az utasitasdekodolas, reszben emiatt keveset fogyaszt. Jott a Jazelle, thumb, thumb2, mindnek volt valami ertelme, es most itt a 64 bit is. Oke, ezekre valoszinuleg szukseg van.
Viszont volt egy x86-os architektura, ami mar 64 bites, de meg mindig a regivel kompatibilis modban indul (real vagy virtual 86 a 386-osok korabol), hurcolja magaval a 16 es a 32 bites osei hulyesegeit, nem veletlenul lett olyan, amilyen. Biztos, hogy ugyanezen az uton kell az ARM-el is haladni? Nem a 64 bittel van bajom, nem mondom, hogy pont ez a lepes lenne felesleges, de van egy rossz erzesem ezzel kapcsolatban.

--
Az emberek azt állítják, hogy múlik az idő, az idő viszont csak mosolyog, mert látja, hogy az emberek múlnak. - tibeti közmondás

Az arm alapvetően 32 bites ha minden igaz. Ott a thumb2 gyk. az arm utasításkészlet 16 bites megfelelője, hogy a kódsűrűséget növelni lehessen, és nem "legacy". Lásd cortex-mX mikrovezérlők.
Nem kötelező mindet implementálni. A Jazelle sincs minden prociban jelen, a NEON se, a Marvell (korábban intel) ARMjaiban meg WMMX is van. Bár nem tudom, hogy ez "fregmentálódásként" hogyan jelenik meg a platformon. Remélem valaki aki fejleszt erre a platformra majd elmondja.

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

Hát nem sok technikai részletről sikerült beszámolniuk.... :/

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

A prezit mar lattad?
Reszletesebbet sehol sem talaltam :(


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Lazan kapcsolodik: up to 128 core,3GHz Server on chip, 10G Eth
"X-Gene is up to three times faster than Intel's Sandy Bridge based E3 Xeons when looking at similar power profile"


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

azt is irjak, hogy mindezt meg csak becslik (pre-silicon), es itt egy tobb ev mulva megjeleno valamirol van szo.
--
zsebHUP-ot használok!

egyébként is baromság az egész, béna parasztvakítás

pre-silicon elott (de RTL utan) a max frekit kiveve tudni illik mire lehet szamitani.
Ha mar majdnem kesz RTL -nel jarnak es mar a ber gyartoval is targyalnak akkor az 1ev siman hiheto dead line.

Az ARM rendszerint (DP) lebegopontos szamitasban szokott elmaradni az x86 -okhoz kepest, nezzunk par regi szamot erre:

Az elozo generacos ARM 2.5Ghz -ig tudott felmenni 28nm -en a mese konyv szerint, 2.0Ghz ig mar gyartottak.
"Single and double precision floating point: up to 2.0 MFLOPS/MHz each"
Ez a regi mar gyartott esetben max. 4GFLOPS/core -t jelenet.

Sandy Bridge max. 32GFlops/core (double) -t tud es 4 core ja szokott lenni (8 szal) (AVX szamitva.) (Az emlitett modelnel lehet, hogy ez elter)

Ezek alapjan a 8 szor erosebb egy Sandy bridge core DP lebegopontozasban, mint az elozo generacios ARM core.

Az emelitett Sandy kb. 80W -ott eszik maxon, amibol 40 active ARM core el meg.

"Advanced SIMD supports DP floating-point execution" (regen a NEON csak SP tudott)
Ha megduplazodott double precizos teljesitmeny, akkor egy core 12GFLOPS -t tolhat.
Egy regebbi core duplaja meg mindig csak a 4-ede annak, amit egy Sandy Bridge core tud.

Csak 32 active corral szamolva 4 core ellen akkor:
32*12/32/4= 3x
(64W)

Ha nem duplazott meg, akkor ~64 core tolna 3x teljesitmenyt, de akkor 128W enne.

Szerintem jol latszik, hogy kozel sem lehetetlen, ha papiron jelzett flopsokat nezzuk.

Lehet, hogy mar valamilyen DDR4 -es elonye is lesz.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ezeknel a celszervereknel nem a cpu kraft az elsodleges szempont, nem tudomanyos szamitasok kiszolgalasara talaljak ki oket, hanem bitlapatolasra kellenek. Ahhoz pedig memoria es io savkeskenyseg kell. Ez jelen pillanatban nincs az arm cpu-knal. Lehet, h ez az armv8-cal meg fog valtozni, de jelenleg nem ez az abra. Multkor jart felenk egy sok magos atom cpu-s csoda amirol hasonlo jokat allitott a gyartoja, hozza teve, h mennyire fasza. Aztan a gyakorlatban kiderult, h az io teljesitmeny fele sem volt annak amit egy normalis szerver bir, az atlagos kiszolgalasi ido pedig a duplajara nott azzal a vassal. Szoval nem kell hasra esni meg az ilyen fasza szamoktol sem, h 3x jobbb!!1111

---
pontscho / fresh!mindworkz

Hat aki egy ilyen rendszerbe nem tesz __legalabb__ 40GB/sec teljes memoria elersi savszelleseget az megerdelmi, hogy kiraktban mutogassak egy "dumb ass" felirattal.

Duplajat illenek hozza tenni. (Ha talalgatnom kene 4xDDR4/DDR3 -et legalabb raknak bele)

Ps.: A ceg I/O centikus dolgokkal foglalkozott eddig, jonehany ceget is felvasarolt a temaban evekkel ezelott.

Ps2.: Sandy Bridge DP/Clock ertekek, ha valakit erdekelne (4Ghz -> 32 GFLops/Core).


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hat aki egy ilyen rendszerbe nem tesz __legalabb__ 40GB/sec teljes memoria elersi savszelleseget az megerdelmi

Nem fogja hozni, ugyanis az arm nem erre lett kitalalva. Az x86-tal ellentetben az arm-nal a fogyasztas az elsodleges ismerv, ott pedig kokemeny kompromisszumokat kell kotni.

---
pontscho / fresh!mindworkz

Ha valakit erdekel Linux mar megy Virtex6 -ra feltolt armv8 -on 64 bitesen: http://www.youtube.com/watch?v=ljhJU4SC97Y&feature=player_detailpage#t=2540s

Az ARM altal addott IP core IMHO joval gyorsabban tud load/storolni, mint egy tipikus L2 cache valaszolni.

note: Manapsag az L2 cache-t kozel teszik ARM-ek is http://www.arm.com/images/amaba-cache-max.gif.

Mit nem hiszel el, hogy :
-Hogy az ARM core core kulso savszelel tud legalabb eleg gyorsan komunikalni?
32 core eseten az mondjuk 2GB/sec felett illene lenni, hogy kulso savszeltol tobb legyen.
A regen tipikusan a hasznalt AXI 64-bites bus szeleseg eseten ehhez 33Mhz orajel kene, az siman megy.

A AXI a interconect-bol nem ritka a 128 biteset ,akkar joval nagyobb orajelen.

Az eddig hasznalt lassu LPDDR2-hoz 64 bitet szokas hasznalni 3.2GB/sec-re belove az orat (a chip rendszerint tudna tobbet is, de ram ugy is lassabb szokott lenni).

Egy corenak tobb interconectje szokott lenni, tehet marad meg mas I/O-ra is, vagy akkar masik ramhoz.

GREEN

-Hogy az LPDDR2 controler helyett lehet betenni a rendszerbe tobb DDR3(4) vezerlot?
http://www.arm.com/products/system-ip/memory-controllers/index.php

GREEN

- Hogy van eleg gyors coherent interconnect ?
10Gb/sec Cache coherent interconnect -tol jobrol nem tudok amit hasznlatak volna ARM-nel, joval kevesebb resztvevovel.

Valami munkat kell vegeznie a cegnek is a profitert :)
Oracle/Sun-nek sikerult oszehozni az Ultra Sparc T3 jo CCX -et, 4xDDR3 , 40nm -chip.
Semmi nem mondja azt, hogy nem lehet megcsinalni ARM -al.

Update:
http://www.youtube.com/watch?v=ljhJU4SC97Y&feature=player_detailpage#t=1980s
Videoban azt mondjak, hogy megoldva, 80GB/sec egyseguk van most. (elsore csak attekertem , sok benne a markting rizsa)

YELLOW
GREEN


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

-Hogy az ARM core core kulso savszelel tud legalabb eleg gyorsan komunikalni?
32 core eseten az mondjuk 2GB/sec felett illene lenni, hogy kulso savszeltol tobb legyen.
A regen tipikusan a hasznalt AXI 64-bites bus szeleseg eseten ehhez 33Mhz orajel kene, az siman megy.

...

Illene, de nincs. Lemertuk tobb arm socon is. Szarra optimalizalt neon koddal atlagosan ennek a negyede van meg a memoria fele, az io meg gyerebb. Tok mindegy, h mennyit irnak ra a memoriara ha az osszes tobbi komponens egy loszar. Nem veletlen varja messiaskent mindenki az A15-ot.

Videoban azt mondjak, hogy megoldva, 80GB/sec egyseguk van most.

Sokszor hallottam mar ezt, majd ha lemertem akkor elhiszem. Ugyanis eddig meg egyik ilyen bemondasra tolt szam nem hozta a hangoztatott ertekeket.

---
pontscho / fresh!mindworkz

N900, ~800MB/sec -nek mertem en is. 166.66Mhz*2(ddr)*(4byte)=1333MB/sec a theoretikus maximum.
1.66* elteres, nem 4* ahogy mondod.

De, ha megnezzuk a masik jatekost, 1600/(2*671) maris csak 1.2* (20%) az elteres.

Nincs ujabb 2Ghz+ csoda rendszerem amit merhetnek. :(

A 80GB/sec -nek a felet elhiheted, mivel ugy is csak kb. 64GB/sec lesz memorai savszele amit mele rakhatnak az elso korben.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

N900, ~800MB/sec -nek mertem en is...

Nem erdekel az n900, reteghardver es celplatform, nem altalanos felhasznalasu, nagy tomegben kaphato hardver. Ez utobbiak pedig nem ezt a kepet mutatjak.

A 80GB/sec -nek a felet elhiheted, mivel ugy is csak kb. 64GB/sec lesz memorai savszele amit mele rakhatnak az elso korben.

Felet sem fogom elhinni, pont a tapasztalataim miatt. Majd ha lemertem a gyakorlatban, akkor fogok kovetkeztetni es "hinni". :)

---
pontscho / fresh!mindworkz

Mondanal egy pelda tomeg hardwaret ahol igazolhato az allitas? Beagle-board ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

az pl iszonyat lassu

--
NetBSD - Simplicity is prerequisite for reliability

166.66Mhz*2(ddr)*(4byte)=1333MB/sec a maximum a mesekonyv szerint (mint az n900), mi a legjobb mert erteked ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"64-bites bus szeleseg eseten ehhez 33Mhz orajel kene" ezet fogalmam sincs honnan szedtem, mert 256Mhz , 128 bit eseten meg 128Mhz.

Ill. a tipukus csak 1.6GB/sec - volt, habar mar az OMAP5 2 csatornan nyomatja, tegra 2 2.4GB/sec (600MT/sec 32 bit).


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Multkor jart felenk egy sok magos atom cpu-s csoda amirol hasonlo jokat allitott a gyartoja

Csak nem a SeaMicro SM10000? ;)

Szoval nem kell hasra esni meg az ilyen fasza szamoktol sem, h 3x jobbb

Arról már nem is beszélve, hogy miben jobb? Mert hogy mindenben nem jobb 3x az ugye egyértelmű. Az meg lehet, hogy egy valami apróságban épp 3x gyorsabb, 20 másikban meg 100x lassabb... Szóval a kijelentésnek így semmi értelme.

Csak nem a SeaMicro SM10000? ;)

Valami hasonloan okos es konnyen megjegyezheto neve volt. Szerintem az osszes marketinges idiota, akinek ez a nev jut eloszor eszbe. :)

Az meg lehet, hogy egy valami apróságban épp 3x gyorsabb, 20 másikban meg 100x lassabb... Szóval a kijelentésnek így semmi értelme.

Ezert szeressuk a marketingeseket. Szerintem kotelezo tanfolyamon vesznek reszt, ahol egyik vizsga kerdes az a "Hogyan mondjunk pozitivan semmit 1000 szoban a semmirol!". :)

---
pontscho / fresh!mindworkz

Nem jelenti azt, hogy most is csak hazudnak.

De konyen lehet a Sandy Bridge veres, meg a 128 core ilyen bedobott dolog, mert azt nem mondtak, hogy egy ev mulva 32+ core-t hoznak, csak hogy hoznak valamit ami legalabb 2 core.

Konyen lehet hogy az elso peldany ,mondjuk csak 8 core-t fog tartalmazni dual DDR3 -al, ami meg nem ver meg egy Sandy-t teljesitemnyben, de performance/W jobb lesz, es nincs mesze Sandy -tol a max teljesitemnye. Mar csak egy jo ar kell es ...


Amit nem lehet megirni assemblyben, azt nem lehet megirni.