Vlákno názorů k článku Příběhy z vývoje nejrychlejšího virtuálního stroje na světě od C - Technická poznámka, ta C verze se uvedeným postupem...

Jakési porovnání s LuaJITem existuje. Sám jsem to moc nezkoumal, ale zdá se, že očekávání byla větší než konečný výsledek.

dík za odkaz. No podle všeho to nechává běžet nad doubly a ne nad integery, takže těžko říct, co by to udělalo při přepisu.

Tak ještě jednou. Předpokládám, že snaha byla porovnat výkon u běžných programů. Aby bylo možné to nějak porovnávat, potřebujete srovnatelný kód ve více jazycích, a málokdo má čas na to psát aplikace pro benchmark, které budou mít desetitisíce řádek a budou dostatečně věrohodně simulovat častou činnost běžných programů, a zároveň to bude měřitelné. Takže ta aplikace pro benchmark bude spíš nějaký jednoduchý kód (jako v tomto případě). Takový kód se dá agresivně optimalizovat, ale pak už to ani vzdáleně nebude připomínat ten častý kód běžných programů, protože v nich bude minimum kódu, který by bylo možné takhle optimalizovat – i když ta optimalizace bude zapnutá.

Extrémním příkladem tedy není zapnutí optimalizací, ale kód, který jde optimalizovat výrazně více, než nejčastější kód běžných aplikací.

Agresivní optimalizace GraalVM podle mne není to samé, jako agresivní optimalizace C kompilátoru – v případě GraalVM jde zejména o optimalizace dynamických jazyků, v případě C jde o optimalizaci instrukcí CPU. Agresivní optimalizace GraalVM podle mne znamená, že prováděný kód je podobný, jako kdyby to byl kód napsaný v C – tedy např. bez několikanásobných referencí, s uložením dat v paměti příznivým pro CPU cache apod.

Je snad jasné, že „nejrychlejší virtuální stroj na světě“ není závěr testu ale hyperbola. Jaroslav Tulach velmi dobře ví, že je nesmysl porovnávat obecně rychlost virtuálních strojů – nikdy nebude jen virtuální stroj absolutní špička, která v čemkoli porazí ostatní. Myslím, že v článku je to jasně napsané.

při určitém počtu elementů začne hrát větši roli vliv cache-miss než jakýchkoliv optimalizací.
A o tom to právě je. Že jakýkoli „hloupý“ interpret dynamického jazyka prohraje kvůli cache-miss hned od začátku, a když se chce VM přiblížit rychlostí kódu psanému v C, musí umět cache-miss vyplývající z dynamické povahy jazyka eliminovat. Na druhou stranu běžné aplikace se s cache-miss běžně potkávají, takže zase nemá cenu dělat benchmark kdy se CPU točí nad jedním řádkem cache, protože to není úplně typický případ běžných aplikací.

Mně se ten argument docela líbí. Ptal jsem se jednou šéfa, co vlastně to naše Truffle API, které používáme na psaní interpretrů, dělá. Dostal jsem odpověď, že: "se stará o to, aby JavaScriptový kód vypadal jako Java". Což mi zní skoro stejně jako "když se chce VM přiblížit rychlostí kódu psanému v C, musí umět cache-miss vyplývající z dynamické povahy jazyka eliminovat". Ano, skutečně je třeba eliminovat dynamickou povahu jazyka a tak nějak se přiblížit typovanému jazyku jako Java/C. Pak to lze přeložit do něčeho, co běží skoro stejně rychle jako C.

V čem se liší nativní cyklus od interpretovaného cyklu? Proč by nemělo fungovat branch prediction? S tou dedynamizací jste na správné stopě. Napovím vám, že lepší termín by byl „deobjektizace“. To asociativní pole totiž typicky neobsahuje hodnoty, ale odkazy na objekty – dynamicky alokované na haldě, takže rozházené po paměti. A to s cache miss souvisí, a to tak že velmi. U dynamických interpretovaných jazyků navíc těch úrovní odkazů bude několik – máte objekty v dynamickém jazyce, a ty jsou zase reprezentovány objekty v interpretu.

Argumenty o neznalost si nechte pro sebe. Netuším, jak jste přišel na to, že většina datových struktur v dynamicky typovaných jazycích jsou ploché mapy s primitivními typy malého rozsahu. Jistě že současné VM dělají optimalizaci některých speciálních případů – vtip nových VM (jako např. GraalVM) je v tom, že dělají optimalizaci většího množství případů nebo lépe. Po GraalVM nepochybně přijde ještě novější VM, která bude optimalizovat ještě více.

Interpret často přidává další odkaz, protože ve své interní struktuře odkazuje na strukturu používanou v interpretovaném jazyce. S branch misprediction jste úplně vedle, způsob zpracování instrukcí je úplně stejný v interpretu i na CPU – zpracovává se instrukce po instrukci, z předchozí instrukce nejde odhadnout, jaká instrukce bude následovat, zároveň ale procesor může zpracovávat víc instrukcí jdoucích za sebou. Navíc moderní VM opravdu nezpracovávají každou jednotlivou instrukci softwarovým interpretem, ale překládají posloupnost instrukcí na strojový kód. Způsob, jakým moderní VM dosahují výkonu srovnatelného s nativním kódem, je takový, že se snaží potlačit dynamičnost jazyka – tj. vygenerují strojový kód pro případ, kdy budou dynamické aspekty zafixované, a před něj dají kontrolu, zda ty zafixované podmínky platí. Díky tomu právě správně funguje branch prediction, protože procesor může spekulativně vykonávat kód pro případ, kdy je daný aspekt fixní, což je ve většině případů splněno. Jedině v případě, kdy se projeví dynamický aspekt jazyka, podmínka splněná není a musí se skočit do pomalé větve, která umí vyřešit tu dynamičnost.

Celá diskuse začala mým konstatováním, že rozdíl výkonu mezi naivním interpretrem dynamického jazyka a VM s kompilací do strojového kódu a optimalizací je z nezanedbatelné části tvořen tím, že taková VM je schopná naservírovat procesoru kód, který redukuje cache miss. Když k tomu nemáte co říct, tak k tomu nic nepište, to je jednoduché.

Polemizujete s něčím, co jsem nikdy nenapsal. Já jsem nepsal, že všechny optimalizace se zaměřují jenom na cache-miss. Psal jsem, že eliminace cache-miss je jeden z cílů optimalizace. O cache-miss jsem psal proto, že jsem reagoval na komentář, který psal o cache-miss.

Když vám na tom tolik záleží, já vám to klidně přiznám. Ano, jistě, máte pravdu, když tvrdíte, že hloupý interpret dynamického jazyka bude mít stejné množství cache-miss jako nativní kód. Jak mne vůbec mohlo napadnout něco jiného. Tabulky virtuálních metod nebo hashtabulky s odkazy na další hashtabulky jsou z hlediska cache-miss stejně efektivní, jako Céčkové struct. Hlavně že už teď budete moci klidně spát.

Interpretru vskutku nic nebrání ve vylepšování, aby se dostal na úroveň V8 nebo třeba až GraalVM. Akorát pak nebude mít smysl dělat porovnání rychlosti jednoduššího interpretru s něčím na pomezí interpretru a VM jako V8 nebo s pokročilou VM jako GraalVM, když budou existovat jen pokročilé VM. Ovšem v mém světě se nepoužívá všude GraalVM nebo něco podobného, v mém světě leckde ještě běží třeba Python 2.

Já jsem nikde nepsal o pouhých dvou možnostech, uváděl jsem to jako dva dostatečně vzdálené body na nějaké škále, takže má smysl porovnávat jejich rozdíly. Pořád ale i ty dva body jsou o jeden bod víc, než váš svět omezený jen na V8.

Jestli VM použije hash table nebo přístup přes index jsem vůbec neřešil. Stále nechápete, že ve světě dynamických jazyků jsou běžné zanořené struktury řešené pomocí odkazů. To je to podstatné, že standardně je to spousta dynamicky alokovaných objektů, a pokud je chce interpret/VM dostat na jedno místo v paměti, musí se o to nějak aktivně snažit.

Jestli je kód interpretovaný nebo zkompilovaný je jenom otázka toho, jak nadefinujeme ten který pojem. Je Java bajtkód zkompilovaný nebo interpretovaný? A je C kód zkompilovaný pro ARM64 spuštěný v emulátoru na x64 zkompilovaný nebo interpretovaný?

Nechápu, proč pořád musíte polemizovat s něčím, co jsem nenapsal.

Stačilo by porovnat nějaké aplikace z reálného světa. Mám aplikaci tu a tu a vím že mi pod GraalVM za daných okolností poběží o tolik % rychleji. To má výpovědní hodnotu. Nebo stačí říct, k jaké změně došlo pokud zákazník XY nasadil ten a ten provoz pod GraalVM. To má taky výpovědní hodnotu, ani není třeba psát komplikované syntetické testy.

A jak byste ty aplikace z reálného světa porovnával? Jak byste změřil, že prohlížeč, textový procesor, grafický editor, videopřehrávač nebo IDE běží o x % rychleji?