
JIT-compilation using GCC 5 - Tsiolkovsky
http://developerblog.redhat.com/2015/04/07/jit-compilation-using-gcc-5-2/
======
userbinator
Bellard's TCC had a similar feature - it could be used to JIT scripts written
in C, and libtcc was its library for dynamic code generation. Being much
simpler it does nowhere near as much optimisation as GCC, but that also means
it can compile much faster:

[http://bellard.org/tcc/tccboot.html](http://bellard.org/tcc/tccboot.html)

 _TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a
typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4._

It'd be interesting to see someone try a similar experiment with libgccjit.

~~~
AceJohnny2
> a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.

Hah! In 2004 (last news) maybe, and I wonder which featureset.

In fact, it's been a long time since I've compiled the kernel myself [1]. I
wonder how long a minimal kernel takes to build nowadays. Of course, I guess
"minimal" is even more ambiguous today than it was back then...

[1] Back in the day, "recompile your kernel" was the Linux joke answer to
problems the way "try turning it off and on again" was for Windows...

~~~
teraflop
On an i3 machine with plenty of RAM and an SSD, and GCC 4.9, a recent kernel
builds in about 3.5 minutes. That's using the "defconfig" target, which is
pretty bare-bones (only ext4, very few device drivers or fancy new features).

As another data point, Debian's kernel configuration on the same hardware
takes 26 minutes to build.

~~~
userbinator
One of the other benchmarks linked to on the page shows tcc compiling 10x
faster than GCC 4.9 -O0 running on the RPi, and 41x faster than GCC -O3:

[http://lists.nongnu.org/archive/html/tinycc-
devel/2013-02/ms...](http://lists.nongnu.org/archive/html/tinycc-
devel/2013-02/msg00043.html)

I think 3.5 minutes down to less than 15 seconds for a recent kernel is
probably possible. On the other hand, tcc generates code which runs 3.5x
slower, so you'd have to be doing a lot of compiling and not much running for
it to save any time. JIT'ing the kernel is a fun exercise, nonetheless.

------
comex
Here are the raw API docs:

[https://gcc.gnu.org/onlinedocs/jit/genindex.html](https://gcc.gnu.org/onlinedocs/jit/genindex.html)

It seems much nicer, if more limited, than the old 'everything is type "tree"'
GENERIC API:

[https://gcc.gnu.org/onlinedocs/gccint/GENERIC.html#GENERIC](https://gcc.gnu.org/onlinedocs/gccint/GENERIC.html#GENERIC)

More competitive with LLVM for projects that don't mind the GPL. I'm looking
forward to finding a project to try it out on.

------
Twirrim
From the perspective of using a JIT within python that the blog post raises
you can see two different approaches of this being done in Python with the
LLVM:

1) The pyston project from Dropbox is an attempt to build a python runtime
sitting on top of the LLVM JIT

[https://github.com/dropbox/pyston](https://github.com/dropbox/pyston)

2) The numba project for python also uses llvm's jit direct from Python, just
requiring you to add a decorator:
[http://numba.pydata.org/](http://numba.pydata.org/)

a quick introduction is here: [http://numba.pydata.org/numba-
doc/0.18.1/user/jit.html](http://numba.pydata.org/numba-
doc/0.18.1/user/jit.html)

------
fafner
I think the GNU Octave folks are using libgccjit to write a JIT for their
Matlab-like language.

------
arez
so did I got it right? If I want to write a script language I can use this
library to implement JIT compiling.

Because with compiled languages that are not running on an VM like JVM it is
impossible to use JIT compiling, because I don't have the source files.

~~~
duaneb
> Because with compiled languages that are not running on an VM like JVM it is
> impossible to use JIT compiling, because I don't have the source files.

Nonsense, you can jit compile either through the JVM (gen bytecode -> bytecode
is jit'd) or through normal ways (llvm, poking memory and protecting it
appropriately, etc.)

~~~
Joky
Did you miss the "not" in "not running on a VM"?

------
the_mitsuhiko
Given that this adds a blob of GPL code into your application I wonder who the
intended target audience is.

~~~
DSMan195276
Well, the blob is only added to the compiler portion of your code. Ex. In this
article, only the Python script is under the GPL because of libgccjit. The .bf
scripts shouldn't/don't have a requirement to be under the GPL.

~~~
rogerbinns
Imagine you had a large application, and wanted to add this library to it. To
comply with the GPL, your application would have to be under a GPL compatible
license. Such applications are a smaller subset of all applications hence the
question.

The LGPL does allow for the library portion to be GPL while the rest of the
app doesn't have to be, but that isn't the license used in this case.
Typically the LGPL favours more widespread adoption, while the GPL favours
freedom at the cost of some adoption.

LLVM also has a JIT and a far more permissive license, making it more
attractive to those not using a GPL compatible license.

~~~
desdiv
>LLVM also has a JIT and a far more permissive license, making it more
attractive to those not using a GPL compatible license.

Not to mention LLVM's JIT is far more mature. If you're reading this on Safari
then LLVM is JITing for you right now:

[https://trac.webkit.org/wiki/FTLJIT](https://trac.webkit.org/wiki/FTLJIT)

