Vlákno názorů k článku
Demonstrace herního enginu Unigine portovaného do JavaScriptu
od Phoenix - Tohle už je fakt zrůdnost. Jděte už s...
-
student (neregistrovaný)
V takom pripade odporucam spustit v javascripte Linux: http://bellard.org/jslinux/ a potom aplikacie spustat az na Linuxe. Myslim, ze prevod aplikacii do niecoho pomaleho a horsieho bude o nieco rychlejsi ;-).
-
Pan X. (neregistrovaný)
Ked uz nieco odporucate, tak to aspon pouzivajte sam, nie len tak si vymyslat. Mozno pride prekvapenie, aka rychla je java, vsak? Ale to nieeeeeee! Java je predsa zla, lebo ludia povedali/napisali. Asi ste s nou nikdy nepracoval.
Ja som napriklad doteraz robil v jave, ale to co s nou posledny rok predvadza orakul ma uz fakt znechutilo. Naproti tomu JS je to najhorsie co som videl za poslednych asi 20 rokov...
K samotnym benchmarkom - neviem komu a ako sa JS zrychlil, ale na mojom 2,5GHZ CPU s 512MB ram to ide hrosie a horsie den odo dna. Asi sa nezrychlil JS ale niekto si testoval na lepsom HW. Ak mi taky "testovaci" zozeniete, kludne upravim svoj nazor na tu prebloatovanu, pomalu, neschopnu sracku. -
jlx (neregistrovaný)
Sorry, ale ses fakt uplne mimo. Evidentne nesledujes vyvoj okolo V8, NodeJS, MongoDB a spol. Pokud pouzivas browser s predpotopnim JS enginem, tak je to fakt jenom tvuj problem.
Jinak problem Javy neni ani tak to, ze by byla pomala (naopak rychlost JavaEE je casto srovnatelna s odpovidajicim kodem v C++), ale to, ze je hodne pametova narocna, zvlast v porovnani s alternativami. Nekdo tomu rika i bloat.
-
Pan X. (neregistrovaný)
Mas pravdu, nesledujem vyvoj JS. Napriek tomu pouzivam prehliadac s najnovsim JS enginom. Pripadne ak existuje nejaky ubertajny projekt prehliadacov, ktore maju este o nieco rychlejsie JS enginy ako tie urcene pre obycajnych smrtelnikov, daj info. Vyskusam...
Pamatova narocnost, ako to budem opakovat uz asi milionty krat nezavisi na jazyku ale schopnosti programatora. Jedina vec, ktora zerie pamat naviac pri jave je JVM, ale samotne aplikacie maju kludne mensiu pamatovu narocnost ako adekvatny program v C/C++ (ano, daju sa najst aj take).
-
Paměťová náročnost samozřejmě nezáleží na jazyku, ale na implementaci konkrétního kompilátoru. Je to trochu o kompromisu, memory manager můžete udělat buď úspornější, nebo rychlejší.
Ten odkazovaný benchmark měří i paměť. Stačí kliknout dole na "Which language is the best" a dát váhu "1" pro Memory a "0" pro Time a délku kódu.
Provnání paměťové náročnosti: zde
-
Riff (neregistrovaný)
To s Javou byla jenom narážka na to tvoje opakování stereotypů, což jsi evidentně vůbec nepochopil.
Java je predsa zla, lebo ludia povedali/napisali.
No a JS je přece špatný, protože to někdo řekl/napsal :-D
K samotnym benchmarkom - neviem komu a ako sa JS zrychlil
Tady jsem jeden pro tebe jeden našel, můžeš se podívat, jak si JavaScript dává jazyky jako Python, Smalltalk, PHP, Ruby, Perl, Lua, Go nebo Erlang. S výroky jako "pomalá neschopná sračka" bych byl příště trochu opatrnější ;-)
-
Pan X. (neregistrovaný)
Len si ma utvrdil, ze chyba je naozaj u teba. Neviem, kde som opakoval nejake stereotypy (na rozdiel od teba a poznamky s javou, ktoru sa snazis schovat za ironiu). Vychadzam vzdy z realnych skusenosti. A JS je zly, nie preto, ze to ludia napisali, ale preto, ze to ludia nahovno urobili.
Skriptovacie benchmarky ma nezaujimaju, pouzivam max Python a Lua. Ale ked pozeram na tu pamatovu narocnost, tak je jasne, preco je JS rychly.
To si mozem rovno hodit kosatku do vane a tvarit sa, ze som pri mori. Asi tak na mna vplyva "uzasme rychly" JS.
Zhrnute - JS je pomala a teraz uz aj nenazrana sracka.
-
lempl (neregistrovaný)
na jednu stranu suhlasim, znasilnovanie scriptovacieho jazyka na co nebol urceny ani navrhnuty je uplne divne a neprirodzene , a zbyocne mrhanie hw vykonom , to rovno mohli konvertovat do BASICu
na stranu druhu osobne dufam ze sa web prehliadac stane nahradou za operacny system, teda ze by bol viac a priamejsie spaty s HW a vytvaral by neaku virtual machine pre kod z netu ktory by na nom bezal , tym by sa odbural nekompatibilita kodu ci prenositelnost a bolo by mozne spustat software ktory nema specialne poziadavky (super vykonnu GPU alebo 7+1 zvukovku) na skoro kazdom zariadeni od mobilu cez tablet a notebook az po desktop ci server no dany system by musel byt tak kvalitne spaty s hw aby jeho vykon vyuzil a nemrhal nim
toto co predvadzaju mi pride ako nehorazne mrhanie vykonom HW, dufam ze to je len ukazka kam smeruje vyvoj prehliadacov a este sa to vyladi aby naozaj dokazali bez medziclankov pracovat s HW kvalitne a bezpecne , a nie kam sa ubera vyvoj aplikaciiosobne mam z takychto prezentaci dost zmiesane pocity a rozmyslam ci je vobec dobry napad pustat sa do ucenia sa HTML a JS ak sa casom zacnu podobne zrudnosti chrlit vsade na okolo a teda bude nutne sa prisposobit trendu
-
jlx (neregistrovaný)
Vzhledem k tomu, ze napr. V8 engine ma v sobe JIT kompiler, tak asi o moc velke plytvani HW nejde.
JS v kombinaci s V8 je momentalne asi nejrychlejsi skriptovaci jazyk vubec (napr. radove tak 10x rychlejsi nez Python). Viz napr.: http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fastest.php
-
lempl (neregistrovaný)
to ze jeden prehliadac vyuziva jadrovy reaktor a stiepene atomy urychluju JS je uplne nezmyselne ak to nie je urcene ako standard a teda nemaju to vsetky prehliadace (aj ked uz sa k tomu asi blizime)
vytvara to iba rozstiepenie standardu a nekompatibilitu napriec prehliadacmi
ano niekomu kto kazde 2 roky kupuje novy pocitac a viac ram atd sa moze zdat ze JS zrychlil 100 nasobne , no ak vytiahnete stare zelezo tak zistite ze zrychlenie je len 10nasobne procom zvysok sposobuje zrychlenie HW
ale musim priznat ze neviem ako by sa dalo riesit urychlenie samotneho JS bez neakych pomocok ci HW zrychlenia , jedine precistenim a prekopanim toho "jazyka" to by vsak zas vytvorilo nekopatibilitu so starsim HW
ale to co som myslel v komentari vyssie je ze JS sa pouziva na to na co nebol urceny ani navrhnuty aplikacie v browseri (cad, documents , 3D hry, atd atd) ano vylepsuju to no v niektorych pripadoch to je skoro az nepouzitelna zalezitost a pritom vacsina to zobere bez toho aby sa pozastavila ci to je efektivne alebo neefektivne spraveny soft
-
Riff (neregistrovaný)
to ze jeden prehliadac vyuziva jadrovy reaktor a stiepene atomy urychluju JS je uplne nezmyselne ak to nie je urcene ako standard a teda nemaju to vsetky prehliadace (aj ked uz sa k tomu asi blizime) vytvara to iba rozstiepenie standardu a nekompatibilitu napriec prehliadacmi
Můžeš nějak rozvést, jak rychlejší zpracování kódu způsobuje nekompatibilitu?
ano niekomu kto kazde 2 roky kupuje novy pocitac a viac ram atd sa moze zdat ze JS zrychlil 100 nasobne , no ak vytiahnete stare zelezo tak zistite ze zrychlenie je len 10nasobne procom zvysok sposobuje zrychlenie HW
Testy se vždycky provádějí na stejném HW, takže zrychlení nespočívá v rychlejším železe ale opravdu v optimalizacích. Jinak se to samé dá napsat o libovolném jazyku :-)
to co som myslel v komentari vyssie je ze JS sa pouziva na to na co nebol urceny ani navrhnuty aplikacie v browseri (cad, documents , 3D hry, atd atd)
A je to opravdu takový problém? I další jazyky se používají na úkoly, ke kterým původně nebyly navrženy a nikomu to nevadí. Pokud s tím máš takový problém, tak online aplikace jednoduše nepoužívej, desktopových alternativ je dost.
-
lempl (neregistrovaný)
" ... Můžeš nějak rozvést, jak rychlejší zpracování kódu způsobuje nekompatibilitu? ..."
to rychlejsie spracovanie kodu je vdaka V8 (o ktorom pise diskutujuci vyssie) ten V8 engine je ale iba v 1 (2 = usudzujem podla wikipedie) webovych prehliacoch takze ak pouzivatel ma iny prehliadac nez tento jeden "vyvoleny" tak ziadne zrychlenie sa nekona, naopak ak zrychlenie kodu pouziva neake obluky alebo nieco vynechava aby bol rychly a potom to nahradzuje neakou svojou random konstantou aby sa tvaril ze to prepocital a pritom nerozbil funkcnost a developer si na tuto "featuru" toho enginu zvykne no zabudne to poriadne spravit pre ostatne (normalne prehliadace) rozbije sa tym kompatibilita vsetci zacnu tlacit iba na jeden prehliadac pretoze ten to roby rychlo (aj ked svojim sposobom) a vsetci ostatny na to budu kaslat ze to je nestandardne
"...Testy se vždycky provádějí na stejném HW, takže zrychlení nespočívá v rychlejším železe ale opravdu v optimalizacích. Jinak se to samé dá napsat o libovolném jazyku :-) ..."
ano da sa to povedat o lubovolnom jazyku a je to aj pravda ked sa clovek pozrie co vsetko v porovnani dnesne aplikacie dokazu "naviac" (pridanu hodntou) oproti starsym ale naopak ake HW poziadavky maju, ano je to vo vacsine pripadov chyba programatora ale tie "prasacinky" ktore vytvara mu musel niekto umoznit spravit, dovolil mu to jazyk
a ano obmedzovat programatora je zle , ale na druhu stranu ak neexistuje obmedzenie tak zvnika bordelk tym testom, malo kedy som videl testy hoccoho robit na rovnako starom zariadeni ako sa testoval napr pred rokmy prva verzia, vzdy je tam nieco novsie v tej zostave a teda nedava to moc velku vypovednu hodnotu , skratka nie su ziadne testy dostatocne doveryhodne
"...A je to opravdu takový problém? I další jazyky se používají na úkoly, ke kterým původně nebyly navrženy a nikomu to nevadí. Pokud s tím máš takový problém, tak online aplikace jednoduše nepoužívej, desktopových alternativ je dost. ..."
v niektorych pripadoch nema clovek na vyber , (internet banking ci firemny system atd) a musi pouzivat co je a alternativy nie su
ano aj ine jazyky sa pouzivaju no neviem o ziadnom inom jazyku ktory by mal tak velku vrstvu prechodov pod sebou hw > os > webbrowser > JS Engine > aplikacia
to je ako davat stolicky na seba a az ked ich bude desat vyliezt na tu najvyzsiu posadit sa na nu a tvarit sa ze sa sedi pohodlne a bezpecne (aj ten najbezpecnejsi a najstabilnejsi system podlahne ludskemu faktoru)
-
Riff (neregistrovaný)
ak zrychlenie kodu pouziva neake obluky alebo nieco vynechava aby bol rychly a potom to nahradzuje neakou svojou random konstantou aby sa tvaril ze to prepocital a pritom nerozbil funkcnost a developer si na tuto "featuru" toho enginu zvykne no zabudne to poriadne spravit pre ostatne (normalne prehliadace) rozbije sa tym kompatibilita vsetci zacnu tlacit iba na jeden prehliadac pretoze ten to roby rychlo (aj ked svojim sposobom) a vsetci ostatny na to budu kaslat ze to je nestandardne
JS engine musí odpovídat ECMA standardu. Jakou rychlostí dokáže pracovat je úplně nesouvisející věc. Proto jsem se předtím ptal, jak to podle tebe spolu souvisí. Takže tvoje vysvětlení s "random konstantou" místo skutečných výpočtů jsem zase nějak nepobral.
-
lempl (neregistrovaný)
"...Vzhledem k tomu, ze napr. V8 engine ma v sobe JIT kompiler, tak asi o moc velke plytvani HW nejde. ... JS v kombinaci s V8 je momentalne asi nejrychlejsi skriptovaci jazyk vubec ..."
lempl > "...to ze jeden prehliadac vyuziva jadrovy reaktor a stiepene atomy urychluju JS je uplne nezmyselne ak to nie je urcene ako standard a teda nemaju to vsetky prehliadace (aj ked uz sa k tomu asi blizime) ... vytvara to iba rozstiepenie standardu a nekompatibilitu napriec prehliadacmi ..."
<<!! to ze to urychluje v jednom prehliadaci neaka featura neznamena ze to bude rovnako rychle v inych prehliadacoch !!>>
lempl > "...to rychlejsie spracovanie kodu je vdaka V8 (o ktorom pise diskutujuci vyssie) ten V8 engine je ale iba v 1 (2 = usudzujem podla wikipedie) webovych prehliacoch takze ak pouzivatel ma iny prehliadac nez tento jeden "vyvoleny" tak ziadne zrychlenie sa nekona, naopak ak zrychlenie kodu pouziva neake obluky alebo nieco vynechava aby bol rychly a potom to nahradzuje neakou svojou random konstantou aby sa tvaril ze to prepocital a pritom nerozbil funkcnost a developer si na tuto "featuru" toho enginu zvykne no zabudne to poriadne spravit pre ostatne (normalne prehliadace) rozbije sa tym kompatibilita vsetci zacnu tlacit iba na jeden prehliadac pretoze ten to roby rychlo (aj ked svojim sposobom) a vsetci ostatny na to budu kaslat ze to je nestandardne ..."
"...JS engine musí odpovídat ECMA standardu. Jakou rychlostí dokáže pracovat je úplně nesouvisející věc. ..."
"...Ale ty tady tvrdíš, že kvůli enginu V8, který tomu standardu odpovídá, budou vznikat nekompatibility. To je prostě nesmysl. ..."nevsimol som si kde pisem , "..ZE KOLI ENGINU V8 KTORY STANDARDU ODPOVEDA.." , mozete mi to ukazat ?
pisem ze vdaka upravam v engine, ktory zacina byt vo vacsine webbrowserov, mozu tieto upravy byt urcene za standard aj napriek tomu ze nepojde o "blaho" webu ale o "blaho" webbrowsera/firmy
tj vacsinova skupina (google, apple, uz aj opera + zvysok stojaci za webkit a V8) urcuje standardy a je jedno ci su dobre alebo zle pre web, urcuju ich preto ze ich chce ta vacsina pre svoje potreby/produkty (webkit ci V8), a ak ta vacsina (google, opera , apple + ostatny odpad) pridu s vylepsenim ze vam bude obrazovka stroboskopicky blikat kym nedostanete epilepticky zachvat a ako vacsinovy vyrobcovia browserov to daju do svojich prehliadacov (chrome,safari,opera ice ...), u developerov sa to zacne brat ako samozrejmost a budu to hojne pouzivat, tym pritlacia W3C organizaciu (kde je apple aj google aj opera clenom) aby sa tato "featura" stroboskopickeho blikania aplikovala ako standard do JS a teda budu to musiet implementovat aj ostatne prehliadace ak budu chciet byt kompatibilny s JS_2.stroboskop.1 , no ked tak spravia v inom engine zisti sa ze ten standard je blbost a rozbija to xy dalsich veci napr ukradnu vam elektronicku penazenku kym sa valate po zemi v epilepsii alebo vam to vytre cely disk, ale kedze tych inych web browserov s rozdielnym ("inym") enginom je malo, myslite ze sa bude na to prihliadat ze v ich engine to nejde aj ked by sa spatne zistilo ze ta chyba je problemom aj v V8 engine z ktoreho ten napad vysiel ? a ak V8 engine pouziva na stroboskopicke blikanie este neake svoje oser kody ale tie v standarde nebudu zahrnute , bude ich mozne bezproblemovo vytvorit aj v inych prehliadacoch bez toho aby si oni rozbili svoj engine?
takze ano ak si neaka skupina firiem stojacich za vlastnym masovo nasadzovanym a pouzivanym enginom zacne upravovat neake svoje featuri a developeri to zacnu brat za samozrejmost, moze tato hlupost casom sposobit nekompatibilitu v standardoch do ktorych to budu chciet spatne natlacit aby to podporovali vsetci bez rozdielu
napr webGL, doteraz nie je uplne bezproblemovy vo vsetkych browseroch pretoze nevedia ako na to alebo to robi hluposti pretoze ak by to spravili ako to robi webkit s v8 , tym by si ozbili cely svoj webbrowser ?
