Komolytalan#24
"Sajnos volt szerencsem az emlitett kodhoz"
Utána meg beleért a kezed a bilibe, és felébredtél.
"Ezeket mar jo ideje nem a cpu szamolja, hanem a gpu."
A GPU az az, amire 2 vinyó tápkábelt is rá kell nyomni, az alaplapról nem tud elég energy-t felvenni? Így aztán megmarad a fogyasztásbeli előny...
Egyébként olyan régen nem számolja ám a GPU, mert mondjuk az általad emlegetett Oracle se használja azt (majd a 18.0-nál, talán, közvetlenül az autoincrement bevezetése után). SQL szerverből ami használ GPU-t az egyedül a PostgreSQL, de annak is csak egy alpha/beta változata, és csak tárolt eljárásban programozhatod a GPU-t, kifejezetten erre szolgáló utasításokkal. Vagyis a normál SQL lebegőpontos utasításokat a GPU egy mákszemnyit sem gyorsítja. Persze lehet hogy fogja, 2-3 windows meg 5 év múlva, talán. Addig azért én nem veszek ARM vasat 200W-ot zabáló GPU-val, ha nem gond.
"A 486-ok kora ota rengeteg dedikalt hardver kerult a gepekbe (pl. gpu-k)"
De hát a GPU programozása még inkább lassú, mint az FPU-é. Ott általában van közte valami busz is, nem tokon belül van a másik egység (kivétel AMD újabb procijai, amik GPU ide vagy oda, gagyik).
"ezert a kozponti processzor manapsag mar sokkal kevesebb lebegopontos muveletet vegez, mivel nincs ra szukseg."
Mert a programok már csak olyanok, hogy beraksz egy GPU-t a gépbe, és onnan kezdve majd azt fogják használni FPU helyett. Végül is csak egy betű különbség...
"Egyebkent meg anno is elvolt a gepek egy resze lebegopontos egyseg nelkul. (sx csalad)"
Persze, maradjunk az egész műveleteknél, és térjünk vissza a fillezett vektor grafikára textura nélkül, ami azokon a gépeken koproci nélkül ment.
"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."
A szövegfeldolgozás az olyan szinten gyors, hogy ahogy gépelsz befelé, már parsolja és szét a legtöbb fejlesztő eszközben. A fordításban az a nehéz, hogy ne mov ax,0, hanem xor ax,ax-re fordítson. Illetve hogy ha van 5 egymást követő független gépi kódú művelet, akkor azokat olyan sorrendbe rakja, hogy azok legjobban ki tudják használni a párhuzamos végrehajthatóságot. Ez ARMnál pláne kritikus, mert ott erre a célra semmi processzorba épített okosság nincs.
"Az android jit-je betolteskor fordit, tehat programinditasonkent egyszer."
Ha nem így csinálná akkor nem is fordítónak hívnák, hanem értelmezőnek...
"A szemetgyujto pedig relative ritkan fut (neha csak tobb masodpercenkent)"
Ritkán is futhat sokáig. De nem is csak ez a gond, hanem a GC algoritmus bonyolultsága. GC algoritmusból is több féle van, mind másra jó, és az adott helyzet függvényében választ ezek közül egyet. Az azért általánosan elmondható hogy egy GC vagy blokkolhatja a kód futását, vagy ha ezt nem akarjuk akkor megszakíthatónak kell lennie, amelyből következik hogy lesz redundancia a munkájában, így összességében jóval kevésbé hatékony lesz, mint a blokkolós algoritmus.
"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."
Hát igen, de miért is van ez így? Mert az ARM alap filozófiája az, hogy legyen egy kis fogyasztású, kvázi tökmind1 hogy milyen buta, de általános processzorunk. Nem baj hogy nincs benne FPU, nem baj hogy nincs benne elágazás előrejelzés, nem baj hogy nincs benne komoly prefetch, nem baj hogy feature listben ott tart mint egy 386-os - lényeg hogy olcsó, és keveset fogyaszt.
Az x86 filozófiája meg a teljesítmény mindenek előtt. Le van tojva a fogyasztás, le van tojva a méret, le van tojva a szükséges gyártástechnológia, le van tojva az ár - egy a lényeg: legyen k.rva gyors.
"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."
Na és itt bukik el az ARM szerver. Mivel szerver szoftver nem sokféle van. Ami kevés féle van, ott átírják x86+GPU hegyekre a szoftvert, és onnan kezdve az ARM labdába se rúg. Hiába hogy ugyanazt a számítási teljesítményt tudja mondjuk 1/2 áramból, ha egy GPU 100x többet tud. Ha meg nem vektorműveletekről van szó, akkor meg ott van az x86 CPU, amely vezérlésben mérföldeket ver az ARMra a nagy cache méret, fejlett elágazás előrelátás, prefetch, stb miatt.