Defining AOT, JIT and Interpreted

Here are a few terms you should get acquainted with if you are dealing with computing. They affect the performance of whatever it is you set your mind into doing.

Assembly

When programming started, we had machine code and then we had assembly. Machine code is what the CPU actually reads and understands while assembly is something “close” to being human readable that is a basic representation in text close enough to machine code.

I dabbled with assembly a bit in my distant past – not the most happy experience I had to say the least.

Compiled

Then you have the compiled programming languages. That’s where C and C++ are located. You write your code in them, and they get compiled to the target machine’s instruction set (=machine code). This works rather well as the interpretation of the program you write is done beforehand, and can take as long as required to optimize the hell out of the code for speed, memory or whatever.

The problem with compiled languages is that there’s a distance between the code you write and the code you run. That compilation step means a delay which means it slows down developers.

Interpreted

Interpreted can be viewed as the other extreme. You write your code in a higher level language and that doesn’t get compiled at all – you run that code through an interpreter that in real time translates that code to machine code as needed and runs the program.

Scripts are built this way.

The good thing about it? Usually easy to write for small programs and easy to modify even while the program is running.

The bad thing? Interpreting means slower running, as the work of understanding something that is easy for humans and transforming that for a machine takes time.

JIT

Just In Time compilation.

This option is a kind of a hybrid between compiled and interpreted. And it is how most Java Runtime Environments work.

The idea behind it is simple. Instead of compiling everything in advance, you compile only what is necessary for the task at hand. Each time to reach a piece of the program for the first time – it gets compiled and from then on, the execution time of that piece of program the following times will be faster.

Languages that get “compiled” to byte-code (Java anyone?) are usually the ones receiving this kind of treatment.

So does Java Script in Chrome.

And Dalvik on Android (anything before Android KitKat).

AOT

Ahead Of Time compilation. This can be seen as the opposite or complimentary technique of JIT.

JIT takes time. When you need to compile pieces of code during runtime this can be intensive in time and CPU. Especially on a mobile device, where the OS is jiggling the various apps in and out of memory as required.

Ahead of Time simply means that instead of waiting until the code gets executed, *someone* takes the initial code (usually byte code) and compiles it for the device it is running on. When you upgrade your Android device these days, it will tell you that it is optimizing the apps – a process that can take several minutes. In essence, this is the ahead of time compilation introduced recently to Android (known as ART). There’s a good explanation here.

Why is it important?

Different languages and environments use different approaches. Each one with its own advantages and challenges.

As we move forward, the world is getting more complex, and a service running in the cloud and on devices is built out of a mixture of these approaches.

There is also the nagging issue of change: things that were once interpreted are now compiled, JIT’d or AOT’d. Just ask Facebook – they now translate PHP to C to make their code compiled instead of interpreted.

Node.js? That’s a JIT for Java Script with a lot of compiled code for the libraries used – which is what speeds it up so much.

Code running in WebRTC? That’s JIT on the Java Script client code, where WebRTC is compiled and wrapped with Java bindings on top of it that utilize JIT and AOT. Going native with WebRTC? It can be compiled, JIT and/or AOT.