Názory k článku
SpiderMonkey: rychlá kompilace JavaScriptu do nativního kódu

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.

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

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

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

Ad 4.: Stačí si přečíst 3. díl tohoto seriálu.

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.

pri vykonech dnesnich cpu...

Ale milionkrát nic umoří i vola ;-)

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

Dekuji autorovi i cele redakci zdrojaku za super clanky. Tento k nim urcite patri take...

Hmm, asi neporovnavaji vysledky u programu ktery jen scita mala cisla a driv nez pretecou tak skonci :-)

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.

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

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.

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

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

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

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.