Programming Languages – Why Are Virtual Machines Required?

compilerprogramming-languages

Instead of compiling the source code for the respective OS (on which it is targeted), you compile once and run everywhere.

For the sake of this question, I would call it VM (for example, both for Java and .NET). So this the execution of programs becomes something like

 ------------       ----      ----
| Executable |  -> | VM | -> | OS |
 ------------       ----      ----

It perfectly makes sense, the compiler remain generic for the respective VM. However, the implementation of VM may vary depending on the machine it is going to be installed i.e. (*nix, windows, mac) x (32 bit, 64 bit).

My question is, instead of writing VM for respective machines, why isn't the compiler is written for that specific machine? By this, instead of downloading respective VM you download the respective compiler and that compiler will take care of the machine-code+OS for that specific machine. End result, the execution of native code for any machine. Definitely, each source code would need compilation for that specific machine but now a days, the automated systems, scm builds can help us do this thing.

Do my reasons of being confused are right or I am missing some bits of technicalities here?

Edit:

PORTABILITY:

Yes, it is one reason but is portability a big issue in today's automated systems? how often do we have to worry about the fact that we don't have to compile it for other machines? Having a code compiled for native machine would give much better performance. Take Java for instance, you can't do low level programming on Windows and you have to choose JNI.

Take automated systems like TeamCity/Jenkins or others. We could have such an automated system setup where code submitted through version control would result in the executable.

Best Answer

My question is, instead of writing VM for respective machines, why isn't the compiler written for that specific machine?

Because then you would no longer have a portable executable; you would have one executable for each platform. The user would have to either download a specific executable for their platform, or compile the code themselves, on their specific platform.

With a VM, each platform just needs its platform-specific VM, and then you can distribute the same executable to every platform.

Related Solutions

Compiler Usage – Are Compilers Used Outside of Development?

Yes and no. Yes, the classical scenario is a developer using a compiler to generate machine code from source code, and the machine code is then distributed to the users.

There are a few exceptions to this though. First, many open source projects are distributed primarily (or even exclusively) in source code form, and expect the end user to install them by typing in a couple of commands like make and then make intall. This will invoke the compiler, linker, etc., to generate the machine code from the source code for that users computer. In these cases, however, the process of building and installing is (at least intended to be) automated to the point that the user rarely needs much knowledge of it beyond the fact that if they've never installed a source code-only package previously, their package manager will typically list some "development" package as a prerequisite for installing the application they really care about (though some still see this as unfriendly to end users).

Another exception (that's been alluded to, but not explained very well in the other answers I've seen) is just-in-time (JIT) compilers. A couple of obvious examples of JIT compilers are the Microsoft Common Language Runtime (CLR) and the Java Virtual Machine (JVM). In these cases, there are normally two entirely separate compilers involved in translating source code into machine code. One is used by the developer. However, rather than generating machine code directly, it generates a machine-independent byte code. The CLR/JVM then includes a second compiler, entirely separate from the first, that converts those byte codes to machine code for the target computer.

I should add that the second compiler isn't strictly necessary. Early versions of the JVM (for one example) just interpreted the byte codes instead of compiling them. This often carries a fairly serious performance penalty though, so most reasonably recent JVMs intended for production use include a JIT compiler.

Why would more CPU cores on virtual machine slow compile times

Answer: It doesn't slow down, it does scale up with # of CPU cores. The project used in the original question was 'too small' (it's actually a ton of development but small/optimized for a compiler) to reap the benefits of multiple cores. Seems instead of planning how to spread the work, spawning multiple compiler processes etc, at this small scale it's best to hammer at the work serially right off the bat.

This is based off the new experiment I did based off the comments to the question (and my personal curiosity). I used a larger VS project - Umbraco CMS's source code since it's large, open sourced and one can directly load up the solution file and rebuild (hint: load up umbraco_675b272bb0a3\src\umbraco.sln in VS2010/VS2012).

NOW, what I see is what I expect, i.e. compiles scale up!! Well, to a certain point since I find:

Table of results

Takeaways:

A new VM core results in a new OS X Thread within the VirtualBox process
Compile times scale up as expected (compiles are long enough)
At 8 VM cores, core emulation might be kicking in within VirtualBox as the penalty is massive (50% hit)
The above is likely because OS X is unable to present 4 hyper-threaded cores (8 h/w thread) as 8 cores to VirtualBox

That last point caused me to monitor the CPU history across all the cores via 'Activity Monitor' (CPU history) and what I found was

OS X CPU history graph

Takeaways:

At one VM core, the activity seems to be hopping across the 4 HW cores. Makes sense, to distribute heat evenly at core levels.
Even at 4 Virtual cores (and 27 VirtualBox OS X threads or ~800 OS X thread overall), only even HW threads (0,2,4,6) are almost saturated while odd HW threads (1,3,5,7) are almost at 0%. More likely the scheduler works in terms of HW cores and NOT HW threads so I speculate perhaps the OSX 64bit kernel/scheduler isn't optimized for hyper threaded CPU? Or looking at the 8VM core setup, perhaps it starts using them at a high % CPU utilization? Something funny is going one ... well, that's a separate question for some Darwin developers ...

[edit]: I'd love to try the same in VMWare Fusion. Chances are it won't be this bad. I wonder if they showcase this as a commercial product ...

Footer:

In case the images ever disappear, the compile time table is (text, ugly!)

Cores in    Avg compile      Host/OSX    Host/OSX CPU
   VM         times (sec)   Threads      consumption
    1           11.83            24        105-115%
    2           10.04            25        140-190%
    4            9.59            27        180-270%
    8           14.18            31        240-430%

Best Answer

Related Solutions

Compiler Usage – Are Compilers Used Outside of Development?

Why would more CPU cores on virtual machine slow compile times

Related Topic