Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

This question already has an answer here:

It occurs to me that there's not a heck of a lot of difference between



$>java module.class

The former compiles to an intermediate language (python bytecode) and executes the program. The latter breaks the steps up, first compiling to the intermediate language (jvm bytecode) and then executing on another line. In fact I can rewrite the python to break out the two steps, as in this SO question.

It seems people make a big deal about the stark difference between compiled and interpreted languages. It seems the lines are entirely blured. Other popular interpreted languages havi similar features. Php "compiles" to its own opcodes which can be cached or stored for later use. Perl also is compiled to something.

So... is there really any difference between these popular interpreted languages and popular compiled languages that compile to VMs? Perhaps in one case the VMs are typically more memory resident whereas with the "interpreted" languages they typically have their runtimes spun up? Yet this seems like it could be easily changed.

Yet there still seems to be something of a difference. If they are more-or-less the same, then why is it that the performance of Java/C# seems to approach C++ while the "interpreted" languages are still an order of magnitude off? If its all truly bytecodes running in a VM, and all really the same, why the big difference in performance?

share|improve this question

marked as duplicate by david.pfx, Wayne M, MichaelT, GlenH7, amon Jul 26 '14 at 21:24

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

IMHO, Java and Python are (almost) in the same category, both interpreted with bytecodes, except that Java has a JIT by default. The real comparison between Interpreted×Compiled would be C and shell script. – marcus Jul 18 '12 at 14:57
Python is dynamically typed. It is the real cause of such a performance gap. Otherwise it would have been trivial to implement an efficient JIT compiler. – SK-logic Jul 18 '12 at 15:13
I'm with @marcus. If Python gets compiled to python bytecode, it doesn't sounds like an interpreted language to me! – vaughandroid Jul 18 '12 at 15:52
This question has been asked many times before in various forms. For example:… – david.pfx Jul 26 '14 at 10:49

2 Answers 2

There are many differences. First of all, think of the difference between a bytecode interpreter and a language interpreter. It's easy to interpret bytecode, because all commands follow a predictable format, but interpreting a language involves parsing and lexing -- operations that can be quite taxing, depending on the language.

C# and Java don't only compile to bytecode. They also use JIT compilation, which allows them to interpert the bytecode a few times for the entire duration of the application, and caching the result -- instead of interpreting it whenever the execution thread stumbles upon it, which would involve lots of redundancy.

As far as I remember, python can compile to bytecode, but it doesn't use JIT, which can drastically increase performance.

share|improve this answer
+1 ah yes very good point about JIT. – Doug T. Jul 18 '12 at 14:44
pypy includes a JIT for python. As does the python library psyco – Timothy Baldridge Jul 18 '12 at 14:54
Does it perform as well as JVM/CLR JITter? – GregRos Jul 18 '12 at 15:57
Bytecode requires parsing as well, unless it's in a fixed-size format. – Mason Wheeler Jul 18 '12 at 16:16
@GregRos In simple cases (i.e. benchmarks), yes. In real-world apps, it's hard to compare, but it can be a couple of times faster than CPython. I guess it's not head-to-head with JVMs and the CLR, but that's hardly surprising since the problem is significantly harder and the budget (and in case of JVM, development time) is much smaller. – delnan Jul 18 '12 at 17:56

Typically, interpreted languages aren't eligible for full-on static analysis (e.g. static type checking across multiple modules) and optimization. Compiling to bytecode can provide this. OTOH, interpreted languages can run even if some parts (libraries, etc.) are missing, because you're late-binding references. IOW, if you don't actually call the code, it doesn't matter if it's there or not.

share|improve this answer
Actually, dynamic-ness (most prominently dynamic typing) makes static analysis hard, but that should be a dead giveaway just from looking at the terms. A language is amendable to analysis or not, how it's implemented is of no interest. Likewise, when a language is just hard to analyze statically, compiling to equally hard-to-analyze bytecode won't help. – delnan Jul 18 '12 at 18:01

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