Komolytalan#13
""- Egy x86 mag durván 10x gyorsabb mint egy ARM mag."
Azonos orajelen kb. 3-4-szer gyorsabb."
De nem azonos az órajel, nem azonos a cache méret - semmi se azonos. Ráadásul míg ARM architektúra kifullad 1Ghz környékén, addig az Intel már 3-4Ghz között jár.
""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."
Félreérthető voltam: a kód alapját nem én írtam, hanem az a fazon, aki a livejasmine szerver oldalát csinálta - nyilván nem ért hozzá. Egyébként meg de, mert 64K-s jar fájlból csinált rtmp szervert, ami azért nem sz.r a konkurensek méreteit és teljesítményét alapul véve. Egyébként a 80-as load papíron azt jelenti amit írsz, a gyakorlatban meg sajnos olyan processeket is beleszámol a load, amely csak "pár" utasítást hajt végre mondjuk 0.00001msec alatt, és utána elengedi a procit. Bár lehet hogy a jelenlegi kerneleknél ez már nem így van - 5 éve még így mutatta. 100-as loadnál még teljesen jól reagált ssh alatt a szerver, a max amit láttam putty-ban az valami 1002-es load volt (és ott még el tudtam indítani a lekapcsoló sh-t).
""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."
Na persze, és ha ugyanarra a memória területre hivatkozna 2 mag - mondjuk egy globális változó területre - akkor mi van? L1 biztos nem maradhat - piha, pár 1000 ütemciklus míg újratölti a szuper memória vezérlő. Márpedig a proci sebességéhez már az L3 is elég messze van, nemhogy a memória.
"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."
Minden adatbáziskezelőnek van fix pontos, lebegő pontos, és egész típusa. Ez durván semmit se bizonyít. Ami számítás igényes az nem egy számla összeg aggregálás, hanem pl egy üzleti szimuláció, amihez meg vastagon kell a craft, így lebegőpontosban számolnak.
"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."
Sokmindent meg lehet csinálni egész számítással, mert pl egyenes rajzoláshoz se kell lebegő pontos, hiába hogy mondjuk a Bresenham algoritmust azt használ. Viszont egész számításból egy lebegőpontos kiváltásához sokkal több műveletet kell használni, mindig. Vagy pedig elveszik a pontosság.
"Minden egyes lebegopontos szamitasra jut par ezer integer/logikai/load/store muvelet."
Ez max 486-on volt így (még ott se 100-es nagyságrend volt az igaz, hanem a 100-as).
"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."
Na igen, de ha az az indítás 5 percig tart - ameddig ARMon egy közepes méretű alkalmazást fordítana egy AOT fordító - akkor azt lehet nem várja ki az user. Ezért kell a JIT fordítónak gyorsnak, és ezzel együtt nem túl hatékonynak lennie.