Demonstrace herního enginu Unigine portovaného do JavaScriptu

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.

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).

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ší ;-)

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.

Kdo chce psa bít... Podle mě i kdyby to lítalo jak assembler, tak ti bude vadit, že to má dlouhej název.

Jo, teď koukám, že link tady už je. Ten výrok s Javou jsem vysvětlil už v předchozím postu - je to jenom z tvojí strany nepochopená ironie, takže chyba bude opravdu mezi židlí a klávesnicí, ale na opačné straně ;-)

" ... 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 bordel

k 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)

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.

ja som neak nepobral vase divne argumenty

takze vsetky JS enginy !MUSI! odpovidat ECMA standardu ? takze vsetky JS enginy su uplne rovnake ?!?

Ale ty tady tvrdíš, že kvůli enginu V8, který tomu standardu odpovídá, budou vznikat nekompatibility. To je prostě nesmysl.

"...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,o­pera 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 ?