Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 12, 2013 11:14 am wrote:
> ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 12, 2013 10:48 am wrote:
> >
> > The primary goal of JIT is to achieve better performance via code specialization.
> > That's the only thing that can beat static compilation.
>
> Nobody sane believes the "JIT can beat static compilers" fairy tales.

That's no fairy tail. The only thing that can beat static compilation is runtime code specialization. The main problem is the high complexity of such a JIT compiler.

> JIT's have other advantages. Performance isn't one of them. They need to get close enough, the "beating static
> compilers" thing was always just a dream, backed up by benchmarks that were completely unrealistic.
>
> The real advantage of JIT is handling stuff that traditional compilers aren't good at. Particularly
> cross-architecture code, but also languages that are (mis-)designed to not have sufficient
> static information, and where you need to do a lot of decisions at runtime.

Most codes in dynamic programming languages contain large parts that are at least in theory compilable statically. So it isn't true that those programs lack static information. The truth is that static compilers either do not exist or are incapable of detecting and using the available static information.

If you take a careful look at Python/Java/Javascript/etc programs you may be able to find that there is a lot of static information in the source code. Simply imagine how you would rewrite the code into C, that's all there is to it.

> Look around you, and ask yourself where people use JIT's.

The implementation of a language can start as an interpreter, or as a compiler generating machine code. Over time, performance concerns force interpreted implementations to be converted to JIT compilers. A JIT compiler takes several years to develop. The primary reason for the 2nd stage being a JIT engine is that it is easier to integrate it into the existing infrastructure than to integrate a static compiler into the dynamic programming language. This does not imply that static compilation of source codes written in the dynamic language is impossible, nor does it imply that static compilation (of initially dynamic languages) would have worse performance than the JIT.

> It's used as a higher-performance alternative to languages
> that were designed for being interpreted (which are often very dynamic in their data types, since for interpretation
> that is very natural and makes things easier for users) and for architecture-neutral languages (ie Java VM and
> variations like Dalvik, but also things like OpenGL and DirectX shader languages etc).

Jitted C done right generates better code than statically compiled C code. If a JIT compiler is constrained to deal with trivial cases then the JIT has no performance advantage over statically compiled C code. So the JIT compiler for C would need to be at least comparable in complexity to the static C compiler. The assumption that JIT compilers have to deal with easy cases only is invalid.

In relation to OpenGL and DirectX: Static shader codes can be compiled statically when the application is first installed onto the computer and when an update is downloaded from internet. Recompilation also needs to happen when the machine changes its graphics card or drivers. None of these cases requires a JIT compiler, so all of this can be done via static compilation and caching.

> So forget the "JITs perform better" crap. It's a bedtime story for retarded gerbils.

If JIT always runs after the static compiler has completed its job then the jitted code by definition performs better. Unfortunately, without reason, the static compilation pass is completely absent in programming languages such as Python or Javascript. Maybe, Javascript and similar languages will obtain a static compilation pass in the future.

There is no equivalent for "gcc a.c; ./a.out" in the Python world, programs are started be typing "python a.py". The form in which static compilation will appear in the dynamic programming language world is via transparent caching and background compilation. At the same time "pythonc a.py" will appear as an option of how to tell Python to statically compile a.py and add the compiled code to its caches.

> The
> real story is "JITs can perform well enough, and have advantages in other areas".
>
> They have their own set of disadvantages too, so it's not an "either or" situation.
> We'll continue to see both, anybody that tells you otherwise is lying.
>
> Linus

The final stage of all static programming languages (including the C programming language) which initially have a static compile-to-machine-code compiler is to hide JIT compilation behind a command such as "gcc a.c". Running this command will perform static compilation. Running the compiled executable will start a JIT compiler. The combination static+JIT will have better performance then static compilation alone.

-Atom