"Megbocsáss, de elég nehezen adhattak ki '87-ben bármit is ARM procival, mikor a cég csak 1990-ben alakult meg, továbbá az elsõ processzorukat csak 1994-ben adták ki ARM7 néven..."
Az arm7 mar a 7. valtozata az arm csaladnak, de a wikipediat elolvasva:
"ARM is a 32-bit reduced instruction set computer (RISC) instruction set architecture (ISA) developed by ARM Holdings. It was named the Advanced RISC Machine, and before that, the Acorn RISC Machine. The ARM architecture is the most widely used 32-bit ISA in numbers produced. Originally conceived by Acorn Computers for use in its personal computers, the first ARM-based products were the Acorn Archimedes range introduced in 1987."
Szoval az, hogy a ceges honlapon elfelejtik megemliteni honnan jonnek nem jelenti azt, hogy a mult nem tortent meg.
"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."
Sajnos volt szerencsem az emlitett kodhoz, tovabbra is azt allitom hogy nem tul jo megoldas, mivel az adott feladatra a tenyleges load joval alacsonyabban tarthato. Altalam keszitett hasonlo kismeretu szerver (http alapu mpeg stream-eleshez) kepes volt alacsony load-on maradni hasonlo user szamnal. A kulonbseg az i/o muveleteknel a blokkolo es a nem blokkolo muveletek hasznalata kozott van. Sehol nem erdemes busy wait-et vagy rovid blokkolast hasznalni, hanem tobb handle-os poll-al kell blokkolni a lehetseges esemenyekre (blockingqueue). A kod nem lesz hosszabb, de a szervert kevesbe terheli. Szemelyes velemenyem, hogy a sracok egyebkent nem mindig jarnak a legalitas talajan... (jogi es nem fejlesztoi szemszogbol)
"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."
Az elso olvasasi muvelet atmegy a ram-ig, a tobbi mar a kozos cache-bol dolgozik. A cache koherenciara pedig tobb megoldas is van, a leggyakoribb a processor interconnect-en kimeno update uzenet, ami szinkronban tartja az L1 cache-eket is.
"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."
Ezeket mar jo ideje nem a cpu szamolja, hanem a gpu. Tehat a cpu lebegopontos egysege gyakorlatilag az ido jo reszeben malmozik... Nem veletlen, hogy a mai x86-osokban sincs dedikalt lebegopontos hardver, hanem a vektoros egyseg kepes emulalni a regi hagyomanyos lebegopontos mukodest. (valamivel lassabban, mivel mikrokodbol megy)
"a gpu-s renderelesed sem allja meg a helyet, 1.5GB memoriaval rendelkeznek ezek a gpu-k"
Olvasd el a Carmack fele megatexture technologia leirasat. Arrol nem beszelve, hogy a szamitasi celra dedikalt nvidia gpu chipek joval tobb ram-ot tudnak kezelni. Csak ezek nem az otthoni felhaszalasra szant kartyakba kerulnek.
""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)."
A 486-ok kora ota rengeteg dedikalt hardver kerult a gepekbe (pl. gpu-k), ezert a kozponti processzor manapsag mar sokkal kevesebb lebegopontos muveletet vegez, mivel nincs ra szukseg. Egyebkent meg anno is elvolt a gepek egy resze lebegopontos egyseg nelkul. (sx csalad)
"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."
A forditas nagyobbik resze a szovegfeldolgozas es a szimbolumtabla kialakitasa. A tenyleges gepi kod leforditasa (az assembly fazis) nagyon rovid. Egy jit fordito eleve az egyik gepi kodbol fordit a masikba, tehat meg egyszerubb feladata van. Az android-os keszulekekben ujabban mar jit fordito van a java-hoz es pillanatok alatt tudnak a dalvik vm es arm kozott forditani. X86-rol arm-ra sem nagyobb feladat, bar az x86-os cpu-k altal mikrokodozott utasitasok relative sok ram-ot foglalnak, de a kod merete az adatokhoz kepest manapsag mar elhanyagolhato.
"sajnos napjainkban a jites mukodes joval lassabb mint 50%, ez a kodforditas, es memoria takaritas miatt van, igen nehezen parhuzamosithatoak ezek a folyamatok, probald megirni"
Az android jit-je betolteskor fordit, tehat programinditasonkent egyszer. A szemetgyujto pedig relative ritkan fut (neha csak tobb masodpercenkent), tovabba rengeteg elozetes info van a program file-okban, igy sok valtozo mar eleve lokaliskent mukodik, azaz nem szemetgyujtott teruletre kerul, hanem a szokasos c-s eletciklust koveti. (igen, pl. a jni mukodese e miatt par helyen elter a szabvany java-tol, viszont az egesz sokkal gyorsabb, bar igy kepes a java-s kod is vedelmi hibat okozni, ami biztonsagi szempontbol gond)
Az intel es az arm processzorok kozott az orajelelterest a gyartastechnologia okozza. Azonos technikval egy arm ketszer magasabb orajelre kepes mint egy x86-os, bar a modern x86-os cpu-k 3-4-szer tobb utasitast tudnak vegrehajtani azonos orajelen, ezert van meg mindig egy kb. 2-szeres elonyuk. Viszont az arm-ok olcso gyartasa, a tobb mag elhelyezese ugyanakkora mereten lehetove teszi hogy nyers eroben jobbak legyenek. Egy nvidia gpu kartya is erosebb egy x86-osnal, csak tul specializalt az altalanos celu mukodeshez. Egy arm valahol a ketto kozott van, tehat megvan a gyors mukodes lehetosege es a nyers ero, de megvan az altalanos cpu tudasa is. Egy arm alapu szerver valahol a ket szelsoseg kozott van teljesitmenyben, tehat egy altalanos x86-os szerver es egy specializalt nvidia gpu cluster kozott. Arban viszont joval mindketto alatt. Egyebkent jopar beagyazott szerver most is arm alapu, pl. a legtobb dedikalt video streaming szerver alapja is arm-os router hardver, csak az emberek altalaban nem tudjak mi van a dobozban.