Tvrdí, že Java potažmo libovolný JIT je rychlejší než C, protože má víc informací než C kompilátor.
Netvrdí. Tvrdí, že zpomalení způsobené překladem bajtkódu do nativního kódu může být kompenzováno nebo dokonce překonáno tím, že kód vytvořený JIT kompilátorem může být efektivnější, než kód vytvořený statickým kompilátorem při překladu ze zdrojového kódu.
Já se k Vám nemohu připojit, ano, JIT může vyhodit určitou část kódu, ale tu může vyhodit i překladač C a Java už z principu nemůže být rychlejší než dobrý C kód.
Jednak JIT může překládat kód pro platformu, na které právě běží. C kód je často překládán pro nějakou obecnou platformu, aby nebylo nutné distribuovat spoustu variant binárek. Za druhé, JIT má informace z běhu programu, které C kompilátor nemá. V případě C se to obchází tím, že se kód spustí v profileru, používá se
typickým způsobem a podle toho se upraví zdrojový kód. Jenže typické způsoby použití se od sebe mohou lišit. Takže efektivní nativní kód jedné aplikace se může lišit podle způsobu použití. Opět by bylo možné přeložit C s různými optimalizacemi a uživatel by si vybral – ale jednak nikdo nemá čas něco takového vyrábět, jednak uživatelé si nechtějí z něčeho takového vybírat.
V teoretické rovině máte pravdu, že JIT nemůže být rychlejší, než ten nejefektivnější kód v C. Přinejhorším se v tom C dá naprogramovat vlastní VM s vlastním JIT kompilátorem. Prakticky se ale něco takového dělá jen velmi výjimečně a je snaha tyhle věci zobecňovat a dostat je už do vývojářských nástrojů (právě ty různé VM).
Ono porovnávat rychlost na CPU nemá moc smysl, ale když už se to dělá, porovnává se běžně napsaný kód jedním způsobem a druhým způsobem. Tedy žádná vlastní VM s JIT v C a žádné JNI v Javě. A v téhle praktické rovině platí, že zátěž, kterou způsobuje překlad bajtkódu, je oproti ostatním vlivům zanedbatelná.