Zamenjava Javascripta

Prav gotovo bo javascript ostal še dolgo. Namreč, tudi če se pojavijo nove tehnologije, starih ne morejo zamenjati samo z argumentom napredka. V bistvu prav razvoju pogonov za javascript izdelovalci brskalnikov zadnje čase povečajo še posebej veliko pozornost. Poleg tega se pri večjih projektih lahko zanašaš na knjižnice tipa jQuery, ki precej skrajšajo razvoj javascripta in zagotavljajo vzdržnost kode tudi v prihodnosti.

JavaScript ima nekaj slabosti, ki se jim z dobro prakso lahko izogneš. Kar ostane je zelo eleganten jezik, ki bo z nami še dolgo. Naslednja verzija, ECMAScript 5, pa prinaša še cel kup novosti in popravlja par največjih zablod, kot so globalne spremenljivke. To bo prihodnost. Glavni problem JavaScripta je ta, da se ga ljudje ne naučijo dovolj dobro. Sintaksa je zelo podobna C-ju in vsak dobi občutek poznanega. Ampak ne bi se mogu obnašat bolj drugače. Ko enkrat dobro razumeš, kako deluje jezik, je zelo ekspresiven.

V glavnem kar se browserja tiče, pozabi na horse power. Računsko zahtevnih zadev se ne računa v browserju, tudi če bi bili JS interpreterji hitrejši.

Preden se preveč razpišemo malo več napiši o sebi. Praviš, da si začetnik - samo v spletnem svetu ali na splošno? Koliko časa že programiraš, koliko izkušenj imaš s programiranjem, optimizacijo, takimi zadevami. Si že kdaj pisal distribuirano kodo?

Tukaj si se podal neposredno v najtežavnejše področje programiranja in ti na tem forumu ne bomo uspeli dolgo pomagati, ti pa lahko pomagamo, da štartaš.

Ne se bat, da ti nočemo pomagat ker si noob. Ampak če si res noob, boš moral sprejet, da pravih konkretnih rezultatov še kako leto ne boš videl, se pa v tem času lahko naučiš, če si iz pravega testa.

Najboljši upgrade za Javascript je CoffeeScript (http://coffeescript.org/). Maš compiler ki ti prevede zadevo v čisto navaden javascript, za Railse imaš celo polno integracijo, mislim da je celo default v Rails 3.1.
Vprašanje je samo v tem ali te stvari v Javascriptu dovolj motijo da bi se "učil" nov jezik. Mene ne. Mi pa zgleda vseeno cool Coffeescript.

PS: Mislim da se kaj drugega razen Javascripta še zelo dolgo ne bo uveljavilo. Tako da so take to-js-compiler variante edine smiselne.

Za paralelno računananje je že dokaj dobro podprt standard "Web workers", dela se tudi na WebCL

ne, se ne lequack. vsaj za hpc niti pod razno ne.
bavec kaj bi rad simuliral, povej kaj vec.

Za začetek loči kaj so tvoje dejanske omejitve in težave katere rešuješ ter kaj je tisto kar si želiš narediti.

Tisto kar so tvoje želje takoj eliminiraj s projekta, ker te se bodo spreminjale iz dneva v dan, pač skladno z trenutno modo in tvojim počutjem.

To da delaš simulacije, še ne pomeni, da so računsko zahtevne in da se ti sploh splača razmišljati o muti-threaded kaj šele grid computingu. Kako računsko zahtevno je tvoje delo, veš ti sam. Zavedaj se edino, da velike večine računskih problemov se sploh ne da paralelizirat (izračun faktoriele na primer). Zavedaj se tudi, da je paralelizacija operacije optimizacijski ukrep in ga ne greš izvajat, dokler nisi izvedel drugih optimizacij.

Genetski Algoritmi so sicer fin akademski buzzword, vendar so strahotno počasni, njihova praktična uporaba pa je omejena. Meni se zdi, da bi rad vse buzzworde spravili na kup, pri tem pa se niti ne zavedaš kaj posamični pojmi pomenijo. Mene kar glava boli, ko prebiram kaj bi ti rad izvedel. Pred instantno zblaznitvijo te brani zgolj tvoja lastna ignoranca :D.

Dovolj moraliziranja.

Skratka, če bi rad naredil rešitev, ki deluje in si že izvedel ustrezne optimizacije:
1. Pravi algoritem,
2. Profajling kode in optimizacija,

Lahko začneš razmišljat o sledečih ukrepih:
1. Če se tvoja koda da paralelizirat, jo sparaleliziraš.
2. Po potrebi jo prepišeš v C - to pa zato, da lahko optimiziraš naprej (po potrebi se spustiš v asembler) - vendar dvomim, da si dovolj dober programer za to.
3. Če še ni dovolj hitro začneš gledat kak Fortran.

Da bi zadevo paraleliziral v brskalniku ali pa celo iz jave prevajal v NodeJS je neumnost. To pa zato ker je vse to počasnejše od Jave. Java ali C sta še najboljša splošno dostopni okolji z ustreznimi performancami.

Na tvojem mestu bi zadevo izvedel takole:

UI na brskalniku, zajemaš vhodne podatke in izpisuješ/izrisuješ izhodne podatke.
Na strežniku bi imel dve aplikaciji - spletno storitev in simulacijski program. Spletna storitev je tam samo zato, da igra brokerja med UI in simulacijskim programom (ki je paraleliziran ali pač ne). Simulacijski program izpisuje simulacijske podatke v nek buffer od koder jih WS jemlje in pošilja brskalniku, tu pa potem rišeš grafe oz. whatever.

To velja samo, pod pogojem, da je tvoj problem dejansko računsko zahteven (ob primerni optimizaciji seveda). V nasprotnem primeru, pa ne kompliciraš in vse goniš v brskalniku.

JRuby uporabljam predvsem kadar rabim kakšne Java libraryje. Na strežniku sicer uporabljam Ruby EE, zaradi porabe pomnilnika, ker imam VPS. Ker namreč laufam predvsem Rails aplikacije, za katere je EE posebej optimiziran glede porabe pomnilnika (je pa npr. še vedno bolj počasen kot JRuby, saj EE ni optimiziran za hitrost). Osebno bom počakal na EE verzijo 1.9ke, ali morda Rubinius. Je pa JRuby definitivno zrel za uporabo, še posebej je smiselno kadar na strežniku že imaš postavljeno infrastrukturo za gostovanje Java aplikacij. Ni bistveno če sem tisti PDF napisal pred enim letom, ker MRI ni več v aktivnem razvoju (samo security fixi). Tako da primerjava z MRI bi morala biti še vedno dovolj natančna.
Blog sem pa izgubil ker mi je crknil disk, pa se zaenkrat še nisem spravljal še enkrat ga postavljat, ker itak nikoli nisem bil nek uber blogger.

Vidim, da bom moral ratat tudi sam bolj programersko pismen, da se bom lahko tudi jaz z vami preganjal, hehe.

Uglavnem, kako procesorsko zahtevno aplikacijo rabim? Tam v diplomski nalogi ste lahko videli, da za število iteracij (ponovitev) obstaja spremenljivka, kar pomeni, da lahko to število določiš sam, več kot je iteracij bolj natančen je izračun. S tega vidika je seveda boljše, da jih je čimveč, se pa pozna na času izračunavanja, razen če delovanje nekoliko pospešimo.

Sedaj, če vas prav razumem mi načeloma predlagate, da simulacijski program pustim v Javi, GUI in izrise grafov sprogramiram pa v NodeJS ter zlinkam med sabo, če je izvajanje zelo zahtevno, drugače je lahko tudi vse v Javascriptu? Sem prav razumel?

Lp Blaž

When we shared the code with ZeptoLab, they were pleasantly surprised by the performance (particularly the speed and smoothness from the game) that we were seeing in modern browsers. To be honest, we had been holding our breath just a little. We expected JavaScript to be fast but the physics calculations were intense and had to happen in real-time. This is a great example of where common preconceptions about the "slowness" of JavaScript turn out to be wrong. The latest generation of JavaScript engines is incredibly fast.

http://www.cuttherope.ie/dev/

Morem rečt, da sem mal premislu in sem se odloču, da bom šel vseeno prevajat program v Javascriptin sicer zakaj:
- Kode niti ni tako veliko za prevest.
- Javascript je standard, ki se bo obdržal in napisana koda ne potrebuje skoraj nobenega supporta (browser ga bo podpiral še najmanj 20 let).
- Poganjanje Javascripta se bo skozi čas še izboljševalo (že sedaj poznamo kar nekaj enginov npr. V8), tudi Java je bila na začetku zelo počasen jezik.
- Na ta način vse deluje v browserju, tudi programiranje je zelo enostavno, razen če zadeva preraste in se izgubiš
- Za grafiko lahko uporabim webGL.
- Omogoča delovanje na širokem spektru naprav kot so PC-ji, tableti, smartphoni itd.
- Na ta način se naučim nov programski jezik, napredek dokumentiram, kar se sklada z raziskovalnim delom na naši fakulteti.

Kakšen komentar na tole mogoče? :)

Lp Blaž

Bavec87 je 11. jan 2012 ob 12:22 izjavil:

- Poganjanje Javascripta se bo skozi čas še izboljševalo (že sedaj poznamo kar nekaj enginov npr. V8), tudi Java je bila na začetku zelo počasen jezik.

To je res v matematicnem smislu. Hitrost JS je nepadajoca funkcija, pocasnejsi ne bo. Zmotno je pa misliti, da imajo razlicni jeziki enake moznosti optimizacije, tako da primerjava s pohitritvami Jave nima osnove. Nekateri jeziki imajo dolocene hitrostne bottlenecke, ki se jih ne da optimizirat stran. Sicer ne vem za JS, vem pa da Clojure naprimer, ne bo nikoli niti priblizno tako performancen kot Java zaradi osnovnih lastnosti jezika. "Optimization will fix the performance gap". Nope.

Bavec87 je 11. jan 2012 ob 12:22 izjavil:

- Poganjanje Javascripta se bo skozi čas še izboljševalo (že sedaj poznamo kar nekaj enginov npr. V8), tudi Java je bila na začetku zelo počasen jezik.

Nekih velikih optimizacij zaenkrat ni za pričakovat, ker že praktično vsak JS engine opravlja JIT kompilacijo, se pa še vedno da odluščit tu pa tam kakšen procent na določenih primerih kode. Rajši poskrbi, da bo tvoj algoritem čimbolj učinkovit.

Bellzmet je 18. feb 2003 ob 19:33 izjavil:

- Za grafiko lahko uporabim webGL.

IE zaenkrat WebGL ne podpira, niti nima načrtov za to.

Problem je samo predvsem v tem, da je kombinacija platform, kjer WebGL dela z pol-spodobno hitrostjo precej bedna (na Linuxu itak ne, Maci majo načeloma tudi probleme s performancom... tam je par Chromeov na Windowsih kjer WebGL demoti pridejo do 20 FPS. Na mašini kjer laufa crysis 2 na high s 100 fps.). Long way to go.

Naj vzame flash oz. svg potem ane. Saj vejretno vektorje rise, ne neke fancy 3d bitne zadeve.

Nekaj sem probaval, pa se mi je zdelo čisto kul glede na to, da je zadeva še jako v povojih. Zato se pa usajam :D

Zanemarljiva razlika... Sicer pa je čisto odvisno od aplikacije do aplikacije. Raje si tule poglej: http://shootout.alioth.debian.org/u64q/... Večinoma so časi enaki, če pa že pogledaš razliko pri posameznih primerih boš pa videl tam primer ko je bil Fortran celo 25x počasnejši. O tem niti nima smisla debatirat, to so neki mejni primeri za katere prevajalnik pač ni ali pa je optimiziran. V teoriji bi morala imet jezika enak performance. Pa tudi v praksi sem ziher da imata v povprečju zelo podobnega, kot je tudi mogoče sklepat iz gornjih rezultatov. Razlika je samo v tem da je v Cju za večino lažje programirat.