⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 13, 2013 5:50 am wrote:
> 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