I know that C has a compiler but what determines execution performance?

For example in an if else block, what if the code just had all ifs instead of if elses, what determines that all the ifs will be ran? In Java it would be the JVM, but in C what is the execution compiler thing?

  • 17
    A useful nuance to learn is that languages are just languages. You could make a compiler that takes C code and makes it run in the JVM for example. – Telastyn Feb 24 '15 at 21:10
  • 10
    +1. This is a very good question. I wouldn't downvote it for its ignorance - it's a wonder more Java students don't ask this. – djechlin Feb 24 '15 at 22:29
  • You can also compile Java to machine code and avoid the JVM... – AK_ Feb 25 '15 at 11:28
  • 2
    Also: Programming Language != Framework != Runtime Library != Compiler != Just in Time Compiler != Interperter – AK_ Feb 25 '15 at 11:31

In Java the virtual machine executes your code, but C compilers generate code that the real machine executes. To be precise, in both cases your program ends up being converted into real machine code, but in the case of Java there's a middle step of compiling to JVM bytecode.

So Java programs are converted to real instructions by the JVM when you load them, whereas C programs are already converted to real instructions by the compiler before they're run.

  • 20
    There are compilers that take Java and produce machine code. For example Excelsior Jet. There are also interpeters for C (picoc) that never generate code that a real machine executes. Languages are languages. Implementations are implementations. Confusing the two can be confusing to people. – user40980 Feb 24 '15 at 21:47

Apart from machine code, there is no programming language in existence which executes directly on hardware, in the sense that you can't feed it the literal source text. All real implementations must translate the source program into the language of the "machine".

For some implementations, it's translated statically. We usually call these implementations "compiled". For others, it's translated into some intermediate form, which is then translated dynamically as the program is run. We usually call these implementations "interpreted". There is a continuum of possibilities between these, and even many modern CPUs do dynamic translation as part of its execution core.

Even when your program is statically compiled long before execution, unless you're writing firmware, it's rare that the compiled code runs directly on the bare metal with nothing supporting it. The operating system provides a virtual machine for user-space programs, often providing such features as the illusion that you have a CPU all to yourself. The illusion of a flat memory space which could be larger than the physical RAM attached to the machine is even called "virtual memory".

On top of that, even when you're programming in C, there is a C virtual machine! It is traditionally referred to as "the C runtime", or CRT for short.

Because C is mostly translated directly into assembly/machine code well ahead of time (on some platforms, there may also be some threaded code, and that can be considered part of the virtual machine), the virtual machine usually only has to handle startup and shutdown.

Startup typically involves setting up the stack and heap; the operating system rarely provides these for you, and it's the job of the programming language to provide these to the programmer. On some platforms there may be some initialisation of signal handling, setting up the "main" thread in a multi-threaded environment, running global constructors on the off chance that the program has been linked to C++ code, handling dynamically linked libraries, or there may be some processing required to set up argc/argv and envp. Finally, CRT transfers control to main.

As for shutdown, many operating systems can kill a process uncleanly, so shutdown doesn't need to do very much. The main thing is to process atexit() calls for the case where the program does exit cleanly.

  • 2
    The C runtime, and the JVM, are completely different beasts. The CRT is just a library. – DeadMG Feb 24 '15 at 23:00
  • I've edited the answer to make things a bit more clear. Incidentally, the JVM and VirtualBox are also completely different beasts. – Pseudonym Feb 25 '15 at 1:23
  • @Pseudonym: not really. Well, okay, VirtualBox is a virtualizer, whereas the typical JVM is an emulator, but if you replace e.g. VirtualBox with QEmu in your sentence, then the two are in fact the same. – Jörg W Mittag Feb 25 '15 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.