Komentáře k článku

SquirrelFish: optimalizace vykonávání instrukcí a nativní kód

Dnes se budeme věnovat tomu, jak urychlit vykonávání instrukcí bajtkódu JavaScriptu ve virtuálním stroji SquirrelFish. Představíme si přitom techniku direct threading, která zrychluje dispatching instrukcí, a další optimalizace. Na závěr článku se podíváme, jak je na tom SquirrelFish s generováním nativního kódu.

Zpět na článek

8 komentářů k článku SquirrelFish: optimalizace vykonávání instrukcí a nativní kód:

  1. Roger

    Pekne
    Clanek je docela pekny (jen jsem moc nepochopil ten skok ke context threadingu na konci).
    Jen drobna poznamka: "Ve většině JIT kompilátorů se totiž…" Treba .NET (aspon v pripade C#, ale myslim, ze je to az na urovni CILu) JITuje taky vsechny funkce uz pri prvnim volani, takze to neni zas az takova vzacnost.

    1. David MajdaAutor příspěvku

      Re: Pekne
      To moje podivení vychází z toho, co jsem v průběhu let o JIT kompilátorech různě četl/slyšel. Ve většině z těchto popisů převažoval přístup "nejdřív měř a pak teprve kompiluj". Je ale možné, že mám zastaralé/zavádějící informace a kompilace funkce při prvním spuštění není vůbec neobvyklá nebo dokonce převažuje.

      Pokud někdo ze čtenářů zná příklady JIT kompilátorů, které to dělají jedním nebo druhým způsobem, napište je prosím do komentářů.

      1. Pichi

        Re: Pekne
        No možná je problém v tom, že zaměňujete JIT kompilaci a HotSpot. To jsou dvě různé věci. To co jste možná až do dneška považoval za JIT kompilaci je HotSpot. To co SquirrelFish provádí je skutečně JIT a může trpět neduhy, které popisujete. Jestli .NET dělá JIT kompilaci netuším, ale slyšel jsem, že se poučili z některých chyb Javy a dělají JIT kompilaci, ale na rozdíl od Javy výsledky ukládají do system wide cache, kdežto Java JIT kompilaci dlouhou dobu prováděla pořád znova při každém spuštění (a hůř i pro základní třídy!) pro každou instanci VM a získala tak onu velmi špatnou pověst s pomalým startem. Pánové v Sunu neměli chuť se pouštět do nějaké formy cache (snad kvůli portovatelnosti a nezávislosti například vůbec na existenci hostujícího OS, čímž si pánové v MS evidentně hlavu nelámali) a tak jim nezbylo než se pustit jinou cestou a HotSpot je výsledek. Kód po překladu do bytecode je nejdříve interpretován a po profilaci jako hot spot je překompilován. To je technologie HotSpot a dá se považovat za jistou podmnožinu JIT kompilace. Java de fakto technologii prosté JIT kompilace opustila. Nicméně je velký rozdíl kompilovat staticky typovanou Javu, nebo C# a dynamicky typovaný jazyk jako je JS. Jestliže u staticky typovaných jazyků má za sebou proces optimalizace výsledného kódu desítky let zkušeností a rozdíl mezi interpretovaným a nativním kódem je propastný, tak v dynamicky typované oblasti se chleba láme právě dnes a právě kolem JS a ta propast teprve musí vzniknout.

        1. Anonym

          Re: Pekne
          mam takovy dojem, ze v tom JIT a hotspot jste se trochu zamotal… ale co…

          nemyslim, ze by kompilace ,,dynamickych jazyku'' byla neco az tak noveho. prekladace LISPu vznikaly uz nekdy pred padesati lety, ktery ,,dnesni'' jazyk tomu muze konkurovat?

          1. Pichi

            Re: Pekne
            Hmm, a víš ty anonymní rozumbrado jaký je rozdíl mezi nativně přeloženým Lispem s typovou anotací a bez ní? To je rozdílek, co? Dtto různé Scheme implementace.

      2. Anonym

        Re: Pekne
        .NET JIT kompiluje vzdy pred prvnim vykonanim funkce, zadny interpret neobsahuje. System je ve vysledku jednodussi, snaze udrzovatelny a hlavne (tohle muze byt pro programatory ze sveta OSS hure pochopitelne ;) snaze otestovatelny.

        Resenim pomaleho start-upu ve svete .NET je NGEN – predkompilace celych binarek typicky behem instalace programu.

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=2893