Most tűnt csak fel (na ja, kissé lassú vagyok), hogy ez a Javascript nem nagyon tűnik valami multicore-t kihasználó dolognak. Nem lehetne az emu-ban valamit párhuzamosítani, pl. a parallel.js-sel vagy effélével?
Ebben a benchmark-ban illusztrálják, hogy mit lehet elérni:
http://ie.microsoft.com/testdrive/Graphics/WorkerFountains/Default.html
Meg egy másik:
http://extremelysatisfactorytotalitarianism.com/projects/experiments/2010/03/boxdemo/index.html
Igen, a JavaScript alapvetoen egy szalu dolog, ezen nehez valtoztatni. Van a WebWorker nevu JS krealmany, ami elso ranezesre annak tunhet az embernek amire vagyik: thread-eket lehet inditgatni, aztan lehet orulni. A problema ezzel csupan az, hogy nem olyan thread ez, pl a valtozok nem osztottak stb, es a worker-ok kozotti kommunikacio igen primitiv es lassu folyamat. Alapvetoen inkabb arra jo, hogy van egy hosszu szamitasi folyamat JS-ben, az kirakod egy worker-be, igy nem akasztja meg az oldalon levo tobbi JS futasat, amig az a hatterben elszoszmotol. Aztan a vegen "jelentkezik" az eredmennyel. Intenziv adatcsere worker-worker kozott nehezkes es lassu, semmikeppen nem alkalmas egy gep emulalasara aztan plane.
Node, vonatkoztassunk el a webtol es a javascript-tol, tegyuk fel, hogy C-ben ir az ember egy emulatort. Vagy akar assembly-ben. Itt persze a thread-ek hasznalata joval hatasossabb lehet, gondolna az ember. Azonban meg itt sem egyszeru a dolog. Eloszor is, ha olyan gepen futtatod, ahol csak egyetlen core van, eleve joval lassabb lesz, tehat ket emu verzio kene, single core-os, es multicore-os. A masik problema az OS: a modern multiask OS-ek eleg komplex dontest hoznak, hogy adott CPU core-on eppen mi fut (az utemezo, azaz a CPU scheduler csinalja). Ez raadasul valtozik is, lehet adott idopontban pont idoszeletenkent egymas utan egy core-on fut a ket thread-ed, maskor meg ket kulon core-on parhuzamosan, hiszen egy modern OS eseten altalaban tobb tucat process var arra, hogy kapjon CPU idot minden idopillanatban. Ez egy gep emulacioja eseten komoly problema. Miert? Nezzuk az EP emulaciot! Nagyjabol pl ami sok idot visz el az a Z80 emulacio, es a nick kepfelepites. Tegyuk egy-egy thread-be. Ekkor az igazi gepet utanozando eleg precizen idoziteni kell, hogy ezek megfelelo szinkronban legyenek. Azaz a ket thread jelentos idejet az vinne el, hogy egymasra varnak. Tippem szerint gyorsabb meg mindig ha inkabb megcsinalod single thread-esre, es meg pontosabb is. Ha most visszaterunk az js/web temahoz, ott a szitu meg rosszabb: ha meg lenne is vmi szuper web worker verzio, amivle nem problema az adatmegosztas, ott az OS-en kivul a browser is elfedi meg jobban a host hw jelleget, tehat meg nagyobb problemakba fogsz utkozni.
Nyilvan egy kis demonal, ahol effekteket mutatnak be ez meg elmegy, de pont fentebb vazoltam, hogy egy gep emulalasnal nem art kb Z80/nick/stb orajel pontossagra szinkronban lenni (amugy ez az JSEP-ben sem teljesul teljesen: az un "nick slot clock" es a Z80 clock aranyat probalja tartani, ami par slot bizonyotalansagot okoz "lebegve" a ket allapot kozott, hogy a Z80 kesik a nick-hez kepest vagy siet, ennel pontosabban megcsinalni joval lassabb lenne).