kvp#6
"- Egy x86 mag durván 10x gyorsabb mint egy ARM mag."
Azonos orajelen kb. 3-4-szer gyorsabb.
"Csináltam média szervert, amely pikk-pakk 40-80-as loadra ugrasztotta a szervert"
Akkor nem tudsz kodot irni. 80-as load azt jelenti, hogy 80-szor tobb szal vart futasra/futott mint ammenyi magja van a gepnek. A busy wait es az os task switcher-enek hasznalata blokkolo muveletek helyett a letezo leg pazarlobb megoldas, bar ha a task switch overhead alacsony vagy sok a cache, akkor nem tunik fel a felhasznaloknak, hogy folyamatosan 100%-on jar az osszes mag. (a villanyszamlat viszont jobb nem nezni) Ha nem akarunk allandoan kapcsolgatni, akkor viszont blokkolo muveletekkel sokkal optimalisabb rendszert lehet kesziteni, ami alacsoynabb orajelen es keves cache melett is jo teljesitmenyt ad. Kodolni tudni kell, mondjuk legalabb a 60-as/70-es evek szintjen, az mar eleg fejlett tudas az emlitett feladathoz.
"Arról az ARMnál mindig szemérmesen hallgatnak, hogy memória, az egy van ám."
Mivel hogy tobb van. Mar pc-kben is 2-3 fuggetlen memoiravezerlo van, videokartyak eseten van amikor 8 vagy 16 fuggetlen memoriamuvelet megy ki egyszerre. A megoldas hatranya, hogy neha akar 16 egyforma ram kartya/chip kell a mukodeshez, elonye, hogy teljesen fuggetlenek egymastol es ha jol van kialakitva az interleave es kozos az L3 cache, akkor kozel linearisan no a memoria teljesitmenye.
"Létező processzorokról beszéljünk. A létező ARM procik egy eleve k.rva lassú, és évek óta nem fejlődő Atom proci sebességét se érik el. Lebegőpontos számításban pláne nem. Fogyasztásban jobbak, de ez az egyetlen előnyük."
Letezo processzor van a telefonomban es megfelelo a sebessege. Egy netbook-ba eleg egy atom is vagy egy atlag mai 1-2 magos arm. Viszont egy 4 magos arm meg mindig kevesebbet fogyaszt mint egy 2 magos atom es kozel azonos a teljesitmenyuk.
A lebegopontos szamitasok az a terulet ami ma nem igazan szamit. Szerver oldalon nem nagyon hasznaljak, mivel uzleti logikanal bcd kell a penzugyek miatt (lasd pl. oracle number format), az alap szerver funkciokhoz (pl. webszerver) pedig eleg a sima integer aritmetika is, amiben az arm-ok ugyanolyan jok mint az x86-osok. Kliens oldalon a grafikahoz nem kell lebegopontos teljesitmeny, azt a videokartya kezeli, a media dekodolashoz vannak dedikalt (fixpontos) utasitasok, mig a os logika tovabbra sem igenyel csak sima integer aritmetikat. Minden egyes lebegopontos szamitasra jut par ezer integer/logikai/load/store muvelet.
"Feltételezve hogy egy JIT fordító azért nem lesz olyan hatékony, mint egy AOT fordító, ráadásul a JIT fordító is prociidőt fogyaszt, mondhatjuk azt, hogy azonos órajel és magszám mellett 1/4 sebesség a max, ami elérhető (és szerintem ez durván hurrá optimizmus)."
Mivel a mai rendszerekben a kod terulet ritkan valtozik (tobbnyire betoltes utan mar read only) es valtozo adatterulet nem hajthato vegre (lasd: data execute prevention), igy a jit gyakorlatilag a kod betoltesekor tortenik, tehat a program inditasakor. Innentol egy sima nativ kod fut. Android eseten ez az atallas 10x-es sebesseg novekedest hozott. Ez technologia a run time branch prediction hianya miatt kb. 50%-os emulacios sebesseget tud hozni altalanos uzleti logikanal, mig kozel 80%-ot vektoros integer feladatoknal (multimedia).
Valtani pedig annyiban eri meg, hogy olcsobban, kevesebb energiafelhasznalassal lehet ugyanazt a teljesitmenyt kapni. Ugyanugy ahogy megerte a processzoron zaljo szoftveres 3D renderelesrol atallni a videokartyak altal biztositott ugyancsak szoftveres, de proci fuggetlen 3D renderelesre. Vagy amiert a HP x86-os szervereiben mips-es halozati gyorsitok vannak (lebegopontos egysegek nelkul), mivel igy kis befektetes (arnovekedes) az adott feladatnal nagy teljesitmenynovekedest hozott.