Saturday, 2 March 2013

Difference between Compiler, Interpreter and Assembler

Lets get some of our concepts clear before to head on to programming in java.This and perhaps next few posts will help you clear some computer programming concepts.

Both compiler and interpreter convert human readable high level language like Java,C++ etc into machine language but there is difference in the way both function.So lets take a look to understand the differences.

Difference between Compiler and Interpreter

Compiler scans the entire program once and then converts it into machine language which can then be executed by computer's processor.In short compiler translates the entire program in one go and then executes it. Interpreter on the other hand first converts high level language into an intermediate code and then executes it line by line. This intermediate code is executed by another program.

The execution of program is faster in compiler than interpreter as in interpreter code is executed line by line.

Compiler generates error report after translation of entire code whereas in case of interpreter once an error is encountered it is notified and no further code is scanned.

Example Python is an interpreted language whereas C,C++ are compiled languages.Java however uses both compiler and interpreter.We will look into how this exactly works in case of java in next post.

Diagrammatic representation-

What is Assembler?

Assembler is used for converting the code of low level language (assembly language) into machine level language.If you have worked on microprocessors like 8085 and 8086 the module which converts assembly language into machine language is nothing but Assembler.

Java - Compiled or interpreted?

As our basics are now clear lets get on to Java. Well you must have heard that Java is both compiled and interpreted language. When it comes to the question - How Java works? It goes something like below -

When you run javac HelloWorld.java java compiler is invoked which converts human readable code(Contents of .java file) to java byte codes(intermediate form). This bytecodes are stored in a special file(called Class file) with .class extension.

Finally when you run java HelloWorld java interpreter is invoked which reads these bytecodes line by line, convert it into machine language and execute it.

This is why Java is called as both compiled as well as interpreted language. But this is not all. There is another concept called - Just-in-time compilation

JIT(Just-in-time compilation)

You can read the wiki page for complete details but here I am only going to provide relevant points from Java perspective.

JIT as the name suggests does just in time or on the fly compilation of java byte codes to native machine language that can be directly executed by the processor.

JIT compiler runs only after the program(JVM) has started. so it has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently.

But question may arise - Addition time is spent every time to compile the code?

Yes it is true if we use pure JIT then additional time is spent compiling every time code is run and hence a new technique was introduced - HotSpot Compiling. In this

JVM maintains a count of number of time a module/routine is executed. When program/JVM first starts it goes through normal compilation to bytecodes followed by interpretation.

But if the count of execution exceeds a limit the corresponding byte codes are compiled to machine code by JIT and are directly executed thereafter.

However if a "hot spot" is encountered - typically a piece of code or method that is getting executed very frequently then JIT compiler comes up. Compiles the byte code to native code with optimizations (as JIT has runtime information) and thereafter that piece of code is never interpreted - the native code generated by JIT is directly executed.

Yes this will have an additional overhead in terms of time and memory footprint as JIT performs optimizations and compilation into native code on the fly (as your application is running) but subsequent calls to that part of code are efficient and fast.