Running in an Intepreted World

One would think that faster processor speeds would make applications run faster and provide a snappier responsive user experience. Reality is of course different and more complex than this. We live in a world of fast application development where code is written in convenient object-oriented languages which run using platform independent byte code; for example, Java, JavaScript, Python, Mono to name but a few. While this is the accepted norm for application development, it's also true in different domains. For example, QEMU does a kind of just-in-time instruction translation and essentially this is a very specialised interpreter, be it machine object code.

More interesting is that Intel PC BIOSs contain AML byte code - this code is in the ACPI DSTD and is interpreted by the Linux ACPI AML interpreter. So even the Linux kernel contains an interpreter to run BIOS ACPI code. But this interpretation of byte code code goes even further in the low-level system side. Soon we will see newer PCs will moving away from the traditional BIOS boot mechanism and using Extensible Firmware Interface (EFI). The boot mechanism allows EFI bootloaders to be compiled into an EFI byte code image using a PE/COFF (Portable Extensible Common Object File Format) executable header. So even the system bootstrapping can run intepreted byte code.

We have a zoo of many flavours of byte code; much effort is put into making them run efficiently on different processors. Some may argue that code is nearly as fast as native code, and the gain from portability and flexibility is a price worth paying at the cost of a slower execution.

Whatever the argument, I do wonder how much longer my laptop battery would last of my CPU was executing compiled native code instead of churning away interpreting different forms of byte code. I'm very curious to find out what percentage of CPU cycles are used in running native code and in running intpreted code, and how this will look in 10 years time.... you never know, perhaps by 2020 large chunks of the kernel will be interpreted(!)