JIT-compilation using GCC 5 | Hacker News Reader

JIT-compilation using GCC 5

developerblog.redhat.com

206 pointsTsiolkovsky25 comments

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

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.

> 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...

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.

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...

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.

I wanted to reverse tccboot to port it to recent kernels, unfortunately it's far above my skills (far^far), I wonder if anyone attempted such a thing.

That's amazing!!!

Here are the raw API docs:

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

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.

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

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/

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

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

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.

> 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.)

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

It is not completely true. See for instance what PNaCl is doing: you can compile C++ (or any similar compiled language) to (LLVM) byte code, and then JIT it at runtime.

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

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.

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.

>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

Is that true? So you can use the JIT compiler in a non GPL project?

You've always been able to use gcc to compile non-gpl code into an executable, and distribute it.

You've always been able to distribute a distro that includes gcc and also includes gpl-incompatible programs (like flash player, or apache-licensed programs).

What has to be GPL is the application that you combine the gcc code with, either when you link in the new libgccjit, or in your python code that imports the python module that links to libgccjit, or if you modify/extend the code for gcc itself (or other GPL codebases).

Can a GPL-licensed interpreter run non-GPL scripts? It seems like one should be able to build a GPL JIT+interpreter as a single application, then run whatever scripts they want on top of it.

The GPL applies to "derivative works", which is a legal term without a precise technical definition.

If you decide to write an interpreter for an existing language, and run existing programs on it, then those existing programs "probably" do not have to be under the GPL, for definitions of "probably" that Legal will not be happy about.

If you write an interpreter for a made-up language and then write programs in that language as part of a thinly-veiled scheme to do an end-run around the GPL, then that "probably" violates the GPL.

There is currently no bright-line rule separating those cases; this is something IP lawyers argue about themselves and reach wildly different conclusions.

The answer is yes. The interpreter is GPL, the programs it runs need not be.

GCC and related projects usually have license clauses to explicitly confirm this, for example https://www.gnu.org/licenses/gcc-exception-faq.html

I write GPL code so I'm fine with that.

Anyone that is happy to use GPL.

Yup, but if you dont modify the code generating that blob the GPL doesn't get upset.

Reply on news.ycombinator.com