18 komentářů k článku SpiderMonkey: rychlá kompilace JavaScriptu do nativního kódu:

  1. Ivan

    Trochu offtopic
    Pro FF je dulezita nejen rychlost JS interpreteru, ale i to jakym zpusobem se pouziva. SpiderMonkey je sam o some multivlaknovy interpret JS. Ve FF ale bohuzel bezi v jednom vlakne a vykonava kod ze stranek i kod z handleru v XULu. To znamena, ze stranka, ktera obsahuje neefektivni JS kod, muze na nejaky cas zablokovat ovladani cele aplikace.

  2. pavel3

    Není to zbytečné?
    Čtení tohoto seriálu mi připadá jako přehlídka zbytečně promarněné námahy chytrých lidí, kteří by určitě mohli dělat neco užitečnějšího než optiomalizaci ECMAScriptu. Nebylo by mnohem efektivnější navrhnout a implementovat pro psaní složitých webových aplikací nějaký pořádný jazyk s jednoduchou a efektivní kompilací, místo ztrácení času na optimalizaci kompilátoru špatně navrženého jazyka? (I když, samozřejmě, jako duševní rozcvička to může být zábavné.) Navíc, právě ty rysy ECMAScriptu, které dělají jeho interpretaci/kompilaci obtížnou, žádný programátor hodný toho jména v životě nepoužije, protože jenom zhoršují porozumění programu a ztěžují jeho udržovatelnost.

    1. ma

      Re: Není to zbytečné?
      To mate to same jako uz mnohokrate diskutovane CISC versus RISC, x86 vs. zbytek sveta a podobne. Jakmile se neco uchyti tak se to stane defakto standartem a jedina moznost jak s tim neco udelat je to proste vylepsit.

      Co se tyce "poradneho" jazyka na psani webu – myslim ze jednodusi bude nejaka uprava v budoucnu (at uz treba ke kvalitni podpore OO, zahozeni problematickych casti nebo i jinak) nez jeho kompletni zahozeni…

    2. David MajdaAutor příspěvku

      Re: Není to zbytečné?

      Mám několik poznámek:

      1. Toho času a lidí „spotřebovaných“ na optimalizaci interpretace JavaScriptu není zas tolik. Jedná se v zásadě o 5 týmů (Mozilla, Apple, Opera, Google, Microsoft) po méně než 10 lidech. Optimalizací interpretů/kompilátorů jiných jazyků, včetně těch navržených pro efektivní běh (C, C++, Java, C# aj.), se strávilo o několik řádů více člověkohodin.
      2. Přijde mi správné jazyka navrhovat primárně tak, aby šetřil čas programátorovi, ne stroji. Reálně je totiž aplikací, pro které bude výkon jazyka omezující, menšina. V případě JavaScriptu pak vůbec nikdo nečekal, že jazyk navržený na psaní malých skriptíků začnou lidi používat na mnohem složitější věci.
      3. JavaScript tu zůstane. Z praktického pohledu nemá smysl mudrovat na nějakým novým jazykem, protože není síla, která by ho prosadila. Stačí se podívat, jak dopadl ECMAScript 4, což byl „jen“ pokus vylepšit stávající ECMAScript směrem, který ve svém komentáři naznačujete.
      4. Můžu vědět, které konkrétní „rysy ECMAScriptu, které dělají jeho interpretaci/kompilaci obtížnou“ a které „žádný programátor hodný toho jména v životě nepoužije“ máte na mysli? Mě osobně napadá asi jen možnost předefinovat metody u objektů, což může být potenciálně docela nebezpečné.
        1. David MajdaAutor příspěvku

          Re: Není to zbytečné?

          Z toho mi přijde opravdu relevantní pouze inspekce zásobníku spojená s prací s argumenty volajících funkcí. To jsem totiž opravdu nikdy neměl potřebu použít a nedovedu si v tuto chvíli představit, jaké rozumné využití by to mohlo mít kromě debuggingu. (Ale má fantazie je omezená :-)

          Ostatní problematické oblasti zmiňované v článku (eval a with) mají své využití (byť omezené). Výkonnostní problémy způsobené příkazem with (zbrždění lookupu) jsou dány jeho podstatou. U eval lze diskutovat o tom, nakolik je nutné, aby uměl ovlivňovat své okolí, a zda by nebylo vhodnější, aby měl svůj vlastní scope. Myslím ale, že use-casy, kde je ovlivnění okolního scope nutné, by se našly.

  3. Tomas Z.

    absence typování a rychlost
    "… absence statického typování v jazyce ve skutečnosti neovlivňuje rychlost jeho zpracování tak moc, jak by se mohlo na první pohled zdát…" … srovnatelná rychlost s C …

    Vím že už to tu bylo v komentářích, ale pořád to nevidím – pokud vím (ať už ze statického typování, nebo z hintů pro kompilátor ala Lisp), že sčítám malá celá čísla a výsledek je rovněž malé celé číslo, můžu generovat jednu sčítací instrukci. Pokud to nevím, musím kontrolovat přetečení do bigintů, nebo riskovat že dostanu špatný výsledek. Pokud je toto v hlavní smyčce (nebo to nekontroluje HW jako údajně v Lisp Machine), rychlosti Cčka se nedosáhne. Jak tohle úskalí chtějí překonat?

    1. ava

      Re: absence typování a rychlost
      Hmm, asi neporovnavaji vysledky u programu ktery jen scita mala cisla a driv nez pretecou tak skonci :-)

    2. David MajdaAutor příspěvku

      Re: absence typování a rychlost

      Nejdřív trochu šířeji: Při opakování tvrzení, že dynamické jazyky mohou být skoro stejně rychlé jako statické, mi jde především o to, abych vyvrátil poměrně zaběhnuté mýty, že musí být řádově pomalejší. Tyto mýty jsou založené na tom, že dynamický jazyk „musí“ být interpretovaný, „musí“ hledat metody a vlastnosti v hash tabulkách a že neznalost typů předem je „drahá“.

      Mýty jsou způsobeny tím, že když člověk dostane do ruky popis dynamického jazyka, přečte si ho a začne přemýšlet, jak by ho implementoval, napadnou ho jen naivní řešení všech možných problémů a z toho usoudí, že to celé musí být hrozně pomalé. Sám jsem tak kdysi uvažoval, takže si to dovedu představit. Tyto úvahy se pak šíří dál a jsou podpořeny i tím, že interprety běžných dynamických jazyků různé naivní techniky často používají a opravdu jsou typicky řádově pomalejší než jazyky statické.

      Celým seriálem se jako červená nit vine myšlenka, že spoustu zdánlivých nedostatků dynamických jazyků z pohledu výkonu lze v mnoha běžných případech chytrou optimalizací téměř eliminovat, což se může zdát překvapivé. Když mluvím o „srovnatelné rychlosti s C“, tak tím nemyslím, že zpracování jazyka bude rychlejší (to až na vyjímky nebude z principielních důvodů), ale že se bude lišit „o malé konstanty“, ne „o řády“.

      Teď konkrétně: Ano, u sčítání se stále musí kontrolovat typ, tj. především zda jde o celé číslo. To je konkrétně ve SpiderMonkey záležitost testu jednoho bitu = 1 nebo 2 instrukce procesoru (nepamatuji si už příliš x86 assembler a nechce se mi hledat). V terminologii TraceMonkey se těmto instrukcím říká guard instructions. Stejně tak se musí kontrolovat přetečení – opět záležitost jedné nebo několika málo guard instructions. Skoky související s těmito testy jsou procesorem dobře predikovatelné, testy tedy nebudou obvykle způsobovat vyprázdnění pileline procesoru.

      V ideálním případě (testy typu a přetečení se vejdou do 1 instrukce) se tedy u cyklu sčítajícího dokola dvě proměnné s čísly dostáváme na něco jako 4 instrukce na cyklus, vs. 1 instrukce na cyklus u céčka. Při složitějších operacích bude overhead menší. Bez statické analýzy bude nějaký overhead existovat stále, podstatné ale je, že to jsou jednotky instrukcí, nikoliv stovky či tisíce, jak je tomu u běžných interpretů.

      Nevím, jestli se mi povedlo dostatečně vyjádřit, jak to se „srovnatelnou rychlostí“ myslím, ale snad ano.

      1. Tomas Z.

        Re: absence typování a rychlost
        První odstavec je asi opravdu klíčový, pak s tím nemám problém. Jen jsem nevěděl, že ten mýtus pořád ještě existuje a je rozšířený.

  4. Jakub Vrána

    Zatím spolehlivě nefunguje

    Já jsem to schválně zkusil na svém zvýrazňovači syntaxe, do kterého jsem shodou okolností zrovna dnes dodělával nějaké optimalizace, a bohužel to zatím nefunguje. Ve skriptu je ošetřen stav, ke kterému by teoreticky nikdy nemělo dojít a přesně k němu v Firefoxu 3.1 Beta 2 se zapnutým javascript.options.jit.content dojde (s vypnutým ne).

    Nahlásil jsem to jako bug 473777.

    1. Jakub Vrána

      Re: Zatím spolehlivě nefunguje

      V 1.9.1b2 to skutečně nefungovalo, v 1.9.2a1-pre to už zdá se funguje. Ke zrychlení mého testu ale bohužel nedojde – naopak došlo ke zpomalení (měřeno Firebugem).

      Firefox/3.0.5 1879 ms
      Minefield/3.2a1pre s vypnutým JIT 1371 ms
      Minefield/3.2a1pre se zapnutým JIT 1765 ms
      1. David MajdaAutor příspěvku

        Re: Zatím spolehlivě nefunguje
        V současnosti ten JIT pořád ladí, takže bugy ani zpomalení mě nepřekvapují. Ostatně nedoladěnost TraceMonkey je hlavním důvodem odsunu vydání 3. bety Firefoxu 3.1.

        Zpomalení bych klidně reportoval jako bug (možná s nějakým omezenějším testcasem).

        1. Jakub Vrána

          Re: Zatím spolehlivě nefunguje
          Možná to doopravdy reportuji, protože moje implementace zvýrazňovače syntaxe je podle mě pro kompilaci ideální – mnohokrát opakovaný cyklus, který se sice hodně větví, ale v zásadě pořád do stejných větví.

    2. peca

      Re: Zatím spolehlivě nefunguje
      Jestli to pomůže, tak mě to nefunguje jenom při zvýrazňování syntaxe v php ostatní syntaxe fungujou…
      Mám tehle prohlížeč: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 a zkoušel jsem to v online demu co je přímo na těch odkazovaných stránkách.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=2915