Např. můžete za běhu generovat nativní kód optimalizovaný podle reálného běhu aplikace, můžete ve virtuálním stroji spouštět dynamické jazyky. Spíš si nejprve zkuste odpovědět na otázku, proč by podle vás mělo být lepší virtuální stroj vůbec nemít. Myslíte si, že zpomaluje aplikaci? Proč si to myslíte? Je to úplně stejné, jako s programovacími jazyky – teoreticky by také nejrychlejší aplikace byly napsané ve strojovém kódu a bylo by lepší vůbec nemít žádný assembler, nebo dokonce C nebo Python nebo Javu. Jenže ve vyšších jazycích se píše mnohem efektivněji a dnešní kompilátory už umí optimalizovat lépe, než by to optimalizoval programátor. Stejné je to i s virtuálními stroji – píše se pro ně efektivněji, a dnes už přichází ta doba, že kód jimi optimalizovaný za běhu se rychlostí vyrovnává kódu optimalizovanému předem kompilátorem.
Ta otázka byla v podstatě rétorická, každý zkušený vývojář ostatně výhody statických binárek zná. Záhadou spíše je, proč javisti zdůrazňují rychlost VM, ta je vskutku (vzhledem ke způsobu práce VM) úctyhodná, ovšem memory footprint je, zejména v případě Javy, v porovnání s jinými, nativně překládanými jazyky, katastrofický. To Java funboys mlčky přecházejí, protože na to neexistuje argument.
Upřímně by mě zajímala reakce od někoho, kdo tomu rozumí a je objektivní.
Zkušený vývojář zná výhody statických binárek, dynamických knihoven, virtuálních strojů i interpretů; zná výhody virtualizace na úrovni OS i kontejnerizaci; ví, jak zhruba fungují dnešní procesory (a že instrukce x86-64 si procesor překládá na vlastní instrukce, takže ve skutečnosti jakousi VM máte už v procesoru); a hlavně ví, že je mnoho různých nákladů spojených s programem – náklady na RAM, náklady na CPU, náklady na IO, náklady na vývoj, náklady na údržbu. U reálných programů se hledá kompromis mezi tím vším. Takže pokud někdo zná jenom výhody statických binárek, není zkušený vývojář. Pokud by vás v tomto ohledu něco zajímalo, musíte se tedy především oprostit od svých předsudků a velmi úzkého pohledu na věc. Jinak totiž tu reakci někoho, kdo tomu rozumí, vůbec nezaznamenáte, protože bude mimo vaše zorné pole.
Pro běh server aplikací jsou optimalizace na VM co jsem tak četl efektivnější, VM může ten běh sledovat a optimalizovat průběžně, ale zas to žere hodně paměti myslím. AOT - tak se jmenuje to spojené s tím překladem rovnou do bináru, tam to takhle optimalizovat nepůjde. A obecně z pohledu vývoje celého řešení a VM a AOT jde proti sobě. Nicméně co vím tak Dart, .NET a asi i Go to mají vyřešené a GrallVM to podle mě také právě řeší.
Jenže AOT je z principu efektivní a JIT se k němu může efektivitou jen asymptoticky blížit (což se na amd64 děje, na ARMu to je zatím veleostuda). Otázka je, co vyváží nevýhody složitého deploymentu, VM je element navíc bez zjevných výhod. To s tím žraním paměti je sice v případě Javy pravda, ale nesouvisí to s VM, prostě má špatně udělanou celou správu paměti, ale tohle není kontroverzní téma, co vidí každý, kdo zná jazyky s kvalitní escape analýzou.
Uvidíme, jestli se vyjádří někdo z týmu GraalVM.
JIT může být efektivnější, než AOT, protože optimalizuje na konkrétní způsob použití aplikace. Pokud toho samého chcete dosáhnout s AOT, musíte nejprve tu aplikaci spustit pod reálnou zátěží, navzorkovat použití, to pak předložit AOT kompilátoru a pak vytvořit novou optimalizovanou verzi. A když se změní zátěž, absolvujete to znovu. Dokonce i ta provedená optimalizace vám může změnit typ zátěže. Takže úplně stejně se dá napsat, že JIT je z principu efektivní a AOT se k němu může asymptoticky blížit a bude to stejně pravdivé, jako to vaše tvrzení. Otázka je, co vyváží nevýhody složitého deploymentu, AOT je element navíc bez zjevných výhod. Nicméně když to vědět nechcete, mlčte místo snůšky polopravd a nesmyslů. Ten váš fanatismus nikam nevede.