ARM számítási teljesítmény

CPU-k, Cooler-ek

Sziasztok!

Minap egyik fórumtéma arra sarkalt, hogy benchmarkokat keressek, amivel összehasonlítható az ARM az x86-tal Linux alatt.

Találtam egyet:
http://www.coremark.org/benchmark/

És néhány további adatot:
http://www.brightsideofnews.com/news/2011/2/21/why-nvidiae28099s-tegra-…

ARM Cortex A9 @ 1 GHz (duál, Tegra 250): 5866 (2 szálon)
ARM Cortex A9 @ 2 GHz (duál, NuSmart 2816): 11661 (2 szálon)

ARM Cortex A9 @ 1 GHz (quad, Tegra 3): 11300 (4 szálon)
ARM Cortex A9 @ 1,5 GHz (quad, Tegra 3): 17000 (elvileg, mivel elvileg 1,5 GHz-en fog futni a végleges)

Intel Pentium III 866: 1945
Intel Atom N270: 4567 (2 szálon)
Intel Atom D525: 9076 (4 szálon)
Intel Core i3 CPU 380M: 19543 (4 szálon)
Intel Core i5-2410M: 28388 (4 szálon)
Intel Core i7 2600: 99562 (16 szálon)

Saját i5-480m -es laptopomon mérve 23962 ( make PORT_DIR=linux64 XCFLAGS="-DMULTITHREAD=4 -DUSE_FORK=1" )

Kérdés: valós procisebesség-mérőszámok lehetnek ezek, vagy ismét az ámítástechnika gyöngyszemébe csúsztam?

  • 8122 megtekintés

( Sanya v | 2011. 09. 03., szo – 22:08 )

véleményem szerint csak ámítás.

( Lacyc3 v | 2011. 09. 03., szo – 23:27 )

Subscrible, örülnék ha valós adatok lennének.

+1
És mint minden esetben, itt is bejön, hogy milyen fordítóval / fordítási opciókkal állítottad elő az eredményt. Persze nem néztem a kódot (ugye a regisztráció :-) ), lehet, hogy a fordítók/optimalizálások nem sokat nyomnak a latban, ellenben korábi PCC/GCC/Clang tesztjeim és "bechmarkjaim" szerint de igenis :-)

( hory v | 2011. 09. 03., szo – 23:38 )

CoreMark is comprised of small and easy to understand ANSI C code with a realistic mixture of read/write operations, integer operations, and control operations. CoreMark has a total binary size of no more then 16K using gcc on an x86 machine (this small size makes it more convenient to run using simulation tools).

Unlike EEMBC’s primary benchmark suites, CoreMark is not based on any real application, but the workload is actually comprised of several commonly used algorithms that include matrix manipulation (to allow for the use of MAC and common math operations), linked list manipulation (to exercise the common use of pointers), state machine operation (common use of data dependent branches), and Cyclic Redundancy Check (CRC is a very common function used in embedded).

Igen, az ARM ennyire eros, a legerosebb+legujabb ARM-ok mar osszehasonlithatoak egy atlag asztali CPU-val.

"CoreMark has a total binary size of no more then 16K using gcc on an x86 machine (this small size makes it more convenient to run using simulation tools)."

Mondjuk azert real world alkalmazast picit nehez ilyennel tesztelni, ugyanis a kodok nem 16K, hanem inakbb 16M fele kozelitenek. 16 kbyte meg egy P1-nek is belefer az L1 cachejebe...

----------------
Lvl86 Troll

Mondjuk teszteléshez egy 16KB-os program is képes lehet megfelelő anyagot generálni szerintem, ez nem hiszem, hogy kizárná a módszer eredményességét.

Amúgy kíváncsi lennék, valójában mennyire összehasonlíthatóak ezek az adatok, tesztelni kellene a programot több gépen ill. körülmény mellett... :)

Szerk.: Mondjuk az ilyen pontozósdinál mindig kérdéses, mit mérünk egyáltalán és amit tapasztalunk, azt hogyan osztályozzuk... más utasításkészlet, más optimalizáció, adott feladat elvégzésének hatékonysága...

Azert nem mindegy, mert az ARM szamitasi teljesitmenyben egesz turheto, de csak akkor ha nem kell memoriahoz vagy egyeb periferiahoz nyulnia. Az pedig valos felhasznalasi korulmenyek kozott eleg valoszinutlen, h csak 16k-nyi adatot kell folyamatosani maszirozni. Ha viszont ki kell lepnie a sajat kis mikrokornyezetebol akkor meghal. A legutolso A8 (igaz, nem A9, itt akar meg fejlodhettek is) atlagosan 250MB/sec-cel volt kepes a memoriahoz hozzaferni. Ha ezt romma optimalizaltuk NEON-ra, akkor nott meg 500MB/s koruli ertekre, de ezt is ugy, hogy kezzel megirtuk az asm kodot es kenyszeritettuk a cpu-t es a memoria interface-t a parhuzamos mukodesre. Ez az 500MB/s pedig otode egy atlagos c2d sebessegenek, ugy egy p3-mal egyenerteku.

Vagy mondjuk vegyunk egy memoria es szamitas intenziv feladatot. Fogj egy tetszoleges high profile h264-et, ezt barmelyik 2.0-as c2d le tudja jatszani per frame threadinggel, viszont egyik arm cpu sem fog cel hw nelkul megbirkozni vele.

Jo az arm, ez nem vitas, de kezeljuk a helyen, kulonben - valos korulmenyek kozott, kilepve a szintetikus tesztek arnyekabol - jonnek a meglepetesek.

---
pontscho / fresh!mindworkz

Ebbol a szempontbol a ketto kozott csak annyi kulonbseg, h az egyikkel csinalsz valamit a masikon. A periferiak/betoltes oldalrol nincs kulonbseg. Plusz egy 16k-s szoftver valos desktop igenyek kozott (es ebbe most ertsuk bele a mobil os-seket is) _nincs_. Ha betesszuk a kepbe a multitaszkot akkor meg plane. Ergo ezek a benchmarkok sok mindennel szolgalnak, de ertekelheto informacioval nem.

---
pontscho / fresh!mindworkz

> "valos felhasznalasi korulmenyek kozott eleg valoszinutlen"

Baromság. A core nyilván ugyanaz a _Core_mark idején, mint a "valos felhasznalasi korulmenyek kozott"

Ha nem hiszed, akkor inkább kérdezd Pontscho-t, ő biztosan érti miről van szó. (Hint: még mindig _Core_mark a téma)

Ez es ez a sommas velemenyem ezekrol a meresi adatokrol.

Mikor az elso tegra3 benchmarkok kijottek az nvidiatol mar latszott, h ezek is kozmetikazott ertekek (amibol kisebb balhe is lett). Amikor valamilyen feladatot akarsz ratenni ezekre a vasakra, rogton elkezdenek konyorogni tobb kraftert. Multkor csinaltam egy szimpla 13 pontos 32x32 pixelen mozgast becslo es atlagos fenyerosseget szamito algoritmust egy A8-ra, a vas azt mondtha h aaaaaaaa, nemar, nem volt kepes ezt a 13kB-nyi adatot valos idoben (30 fps-sel) valos felhasznalasi korulmenyek kozott feldolgozni addig a pillanatig amig az egeszet at nem irtam NEON-ra, ahol a memoria busz az utolso orajelig ki nem lett hasznalva. Ezen a feladaton a total unoptimalis zagyva prototipus kodon es adathalmazon barmely desktop cpu rohogve rongyolt volna vegig nanoszekundumokban es nem milliszekundumokban mert ido alatt, mint ahogy ez egy atlagos arm boardon most epp tortenik.

---
pontscho / fresh!mindworkz

Ráadásul a Tegra 2-ben nincs NEON. Volt meglepetés, amikor NEON-ra optimalizált kódot próbáltunk rajta futtatni. De hát úgyis mindent, amit csinálni akarhatsz a GPU majd gyorsít...oh wait. :)

Nem baj, Tegra 3-ból már elvileg nem spórolták ki. A memory bandwidth-jéről ennyit találtam hirtelen:
"Surprisingly enough, the memory controller is still a single 32-bit wide LPDDR2 controller. NVIDIA believes that even a pair of Cortex A9s can not fully saturate a single 32-bit LPDDR2 channel and anything wider is a waste of power at this point. NVIDIA also said that effective/usable memory bandwidth will nearly double with Kal-El vs. Tegra 2."

Üdv,
Gergely

Pedig az arm neon nelkul olyan mint a chillis bab chilli nelkul. Van, de minek. :)

Megint itt van az a fiasko, h ez egy vendor altal kiadott doksi, raadasul olyan gyarto altal amelyik mar megmutatta, h imad kozmetikazni. Szeretik az arm socokra rairni, h "ddr3! gyorsak vagyunk!", de a gyakorlatban csak annyit er ez a kitetel, h olcsobb ram is jo hozza, sebessegben semmit nem jelent. :)

---
pontscho / fresh!mindworkz

( STP | 2011. 09. 04., v – 11:02 )

És ha pl. a SuperPI gyorsabban fut(na) GPU-n mint CPU-n, mi lenne a kérdés?

( salaud v | 2011. 09. 04., v – 11:19 )

Érdekes egy teszt azért ez, nézegettem processzorteszteket, ahol a core i5-ök rendre hozták az amd natív négymagos processzorainak teljesítményét, most meg kíváncsiságból lefuttattam, az eredmény: 33859. Mindez egy AMD Athlon(tm) II X4 640 Processor, DDR2-800-as ramokkal. Más szóval netes tesztek olvasgatása ennyit ér szvsz.
---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Figyelj arra, hogy paraméterezned kell, hány szálon akarod parallel futtatni. Default 1 szálon (= 1 magon) tesztel, bárhány magod van. Lásd még eredeti vitaindítómban írt paraméterezést.

Továbbá a hyperthread mag értelemszerűen közelébe sem ér a valós magnak.
Ja és laptop procik esetén a hőterhelhetősége is visszaszabályozza a procit (i5-480m -nél néztem, melegen HT nem hozott már annyi többletet).

Pontosan ugyanúgy futtattam, mint te. 8 szálon már 36000 feletti eredmény jött, 16 szálon ~38000.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Hmm. Egyvalamire gondolok, de csak tapogatózok. A több szál "jobban kiéhezteti" a többi folyamatot az ütemezőben a jelen teszt javára. Elővettem az Athlon XP 2400+ -os klasszikus gépet, mert az tuti nincs hőmérsékletre visszakorlátozva (laptopommal ellentétben) .

1 szálon: 5066.79
2 szálon: 5073.80

Igen, ezt írtad, több szál, magasabb érték. És most jött a furfang: root és nice -n -20 bash majd ugyanitt 1 szálon:

1 szálon, de -20 -as nagypriorítást adva: 5072.63

Ha nem vert át valami, akkor magyarázatot ad a jelenségre: úgy néz ki, hogy háttérfolyamatoktól rabolsz a sok szállal több erőforrást. Feltéve, hogy nem tévedek.

Ezek kb. annyira elenyeszo kulonbsegek, hogy hibahatar otodet sem eri el (egyaltalan hanyszor merted?)

Egymagos CPU-n eleve sok kulonbseg nem lesz az 1-2 szal kozott, maximum specialis esetekre mikrooptimalizalas, amely kb. ilyen toredekszazalekot jelent. Viszont, ha mondjuk nem 1-2 szalon, hanem 20-50 szalon teszteled, mindjart mas lesz az eredmeny, ahol mar tobbet fog futni az utemezo.

De amugy mint fentebb ki lett targyalva, az egesz cucc (mind kod, mind adat) elfer az L1 cacheban, igy kb. arra jo, hogy az egyes CPU-k nyers matekolasi teljesitmenyet merjek. Azaz gyakorlatban semmire, ugyanis a valos felhasznalasrol (ahol mar megas adatok jonnek be a kepbe) az eg vilagon semmit nem mond el.

----------------
Lvl86 Troll

( uid_720 | 2011. 09. 04., v – 12:22 )

A nürnbergi beágyazott rendszerek kiállításon láttam számos eszközt, amiben Cortex-A9 volt (idén ez volt a hívószó, tavaly pedig a Cortex-M3), legtöbbször Ununtut futtattak, és elég reszponzív volt a rendszer.

Nagyon tetszett, hogy a Xilinx, az NVidia és az ARM (meg pár hasonló garázscég) is Linuxszal demózott :-)
Sőt, beszéltem egy skót sráccal (aki az ARM-nak dolgozott), ő éppen azt mutogatta a vendégeknek, hogy hogyan lehet a csodaprogramjukkal távolról Linux kernelt debugolni :-) Kaptam is tőle egy raklapnyi dokumentációt.

Szerintem jövőre is megyünk (jön a topikindító is! :-D), hátha addigra a Cortex-A15 lesz a menő.

Fuszenecker_Róbert

( Mcsiv v | 2011. 09. 05., h – 09:14 )

Teljesen felesleges architektúrálisan eltérő rendszereket összehasonlítani. Egyrészt mert lehetetlen, másrészt meg mind a kettő eszköz, és mint mindig, a cél határozza meg az eszközt.

( Quain | 2011. 09. 05., h – 11:47 )

Kocsis hasonlat:
Arm: autómotor, biciklikerékkel.