Hlavní navigace

Vlákno názorů ke zprávičce Demonstrace herního enginu Unigine portovaného do JavaScriptu od Phoenix - Tohle už je fakt zrůdnost. Jděte už s...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 21. 2. 2013 18:21

    Phoenix (neregistrovaný) ---.pilsfree.net

    Tohle už je fakt zrůdnost. Jděte už s tím JavaScriptem do prd***. Prohlížeč je od toho aby se v něm prohlížely webové stránky (HTML) a ne aby se nativní rychlé aplikace převáděli do něčeho co je pomalejší a horší.

  • 21. 2. 2013 19:39

    student (neregistrovaný) ---.kolej.mff.cuni.cz

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

  • 21. 2. 2013 20:42

    lempl (neregistrovaný) 2607:5300:60:----:----:----:----:----

    da sa tam neak dostat android ? :D

  • 21. 2. 2013 22:54

    Pan X. (neregistrovaný) 78.141.73.---

    Uz sa to previedlo do JS, nic pomalsieho a horsieho v sucasnosti asi neexistuje.

  • 21. 2. 2013 23:45

    Riff (neregistrovaný) ---.cust.nbox.cz

    Omyl, dá se to napsat v Javě :-) Jinak co si místo opakování stereotypů najít třeba nějaký aktuální benchmark porovnávající rychlost jednotlivých jazyků? Budete asi (ne)mile překvapený, jak moc se JS za posledních pár let zrychlil.

  • 22. 2. 2013 12:52

    Pan X. (neregistrovaný) 78.141.73.---

    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.

  • 22. 2. 2013 13:09

    jlx (neregistrovaný) ---.net.upcbroadband.cz

    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.

  • 22. 2. 2013 13:32

    Pan X. (neregistrovaný) 78.141.73.---

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

  • 22. 2. 2013 13:52

    Blaazen

    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

  • 22. 2. 2013 13:56

    Riff (neregistrovaný) ---.cust.nbox.cz

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

  • 22. 2. 2013 19:23

    Pan X. (neregistrovaný) 78.141.73.---

    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.

  • 22. 2. 2013 20:00

    Riff (neregistrovaný) ---.cust.nbox.cz

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

  • 22. 2. 2013 13:01

    Pan X (neregistrovaný) 78.141.73.---

    Tu nizsie niekto dokonca pridal link na taky pre vas dolezity benchmark. Ak som to dobre precital a pochopil, tak ta java je rychlejsia ako JS... Nebude niekde u vas chyba medzi stolickou a klavesnicou?

  • 22. 2. 2013 14:00

    Riff (neregistrovaný) ---.cust.nbox.cz

    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ě ;-)

  • 21. 2. 2013 20:34

    lempl (neregistrovaný) 2607:5300:60:----:----:----:----:----

    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 aplikacii

    osobne 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

  • 22. 2. 2013 9:58

    jlx (neregistrovaný) ---.net.upcbroadband.cz

    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

  • 24. 2. 2013 13:25

    lempl (neregistrovaný) 198.144.184.---

    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

  • 24. 2. 2013 16:19

    Riff (neregistrovaný) ---.cust.nbox.cz

    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.

  • 26. 2. 2013 0:19

    lempl (neregistrovaný) ---.vectro.com

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

  • 28. 2. 2013 9:39

    Riff (neregistrovaný) ---.cust.nbox.cz

    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.

  • 28. 2. 2013 22:51

    lempl (neregistrovaný) 199.195.252.---

    ja som neak nepobral vase divne argumenty

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

  • 28. 2. 2013 23:04

    Riff (neregistrovaný) ---.cust.nbox.cz

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

  • 1. 3. 2013 22:15

    lempl (neregistrovaný) 199.167.133.---

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

  • 22. 2. 2013 6:09

    Rudolf Klusal

    Takhle bych to asi nenapsal, ale naprosto souhlasím :-D