Interpreted languages: The higher-level the faster?

Question

I have designed around 5 experimental languages and interpreters for them so far, for education, as a hobby and for fun.

One thing I noticed: The assembly-like language featuring only subroutines and conditional jumps as structures was much slower than the high-level language featuring if, while and so on. I developed them both simultaneously and both were interpreted languages. I wrote the interpreters in C++ and I tried to optimize the code-execution part to be as fast as possible.

My hypothesis: In almost all cases, performance of interpreted languages rises with their level (high/low).

• Am I basically right with this? (If not, why?)

EDIT: I didn't mention the word compiled here even once, it is about interpreted versus interpreted!

Answer 1

In both cases you are interpeting code. I would imagine in the higher level languages you have fewer instructions to achieve the same task, so you are spending less time interpreting instructions and more time doing something useful.

Answer 2

In the end, parsing a line of text in your language is going to take roughly the same amount of time whether we're talking about assembly versus The Next Big Thing Language (TNBL). This isn't true in a literal sense, but it is true in a Turing-esque, Big-O-Notation sort of way.

If it takes (again, "roughly") the same amount of time to determine what this means:

mov $3, $4, $5

as this:

print "foo"

...then let's imagine writing Hello World in our two languages. The assembly interpreter is going to have a much more complex program to parse. Say, n lines long, which is n times as many lines as the TNBL Hello Wolrld. So your most basic overhead is n times as long.

On top of that, you have all the code that you execute in the simpler language that models the behavior of registers, operations, etc. It's a lot of work. In TNBL, there's nearly a one-to-one mapping between the semantics of the interpreted code and something you can do in the host language. This means a greatly reduced overhead in going from semantics to execution.

I'm sure you'll see some Java programmers who would balk at this thesis, but I would point out that Java has a couple of advantages going for it: an intermediate bytecode that tries to get the code as close to the hardware as possible before executing it, and thousands of man-years sunk into developing compile-time and run-time optimization of that language. They are hardly on the continuum with a hobbyist language. =]

Answer 3

The reality, of course, is slightly more complicated than that. As languages, interpreters and compilers become more sophisticated, new opportunities arise for the machine to optimize performance. Further, the performance of any given program depends greatly on the quality of the code that the programmer has written.

Also, performance affects different types of programs in different ways. Line-of-business applications, for example, almost always take most of their speed hit looking up data from a database and sending it across the wire, whereas game programmers must deal with a completely different concept of performance, namely that of video card frame rates.

So the performance picture is not nearly as simple as it might seem.