Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

> In this post I hope to show that while the interpreter adds overhead, it is not the dominant factor for even a small microbenchmark. Instead we'll see that dynamic features -- particularly, features inside the runtime -- are to blame.

I'm probably uneducated here, but I don't understand the distinction between the runtime and the interpreter for an interpreted language? Isn't the interpreter the same as the runtime? What are the distinct responsibilities of the interpreter and the runtime? Is the interpreter just the C program that runs the loop while the runtime is the libpython stuff (or whatever it's called)?

View on HN

Concretely they are the same, for an interpreted language.

I think the distinction they are trying to make is between slowness due to general constraints on interpreted languages vs. slowness because of particular features or implementation details of CPython's runtime.

It is kind of like, bicycles are slower than motorcycles, in general. Let' say I have a Snake 3000 bicycle with a max speed of 4mph. And people say, it's slow because it's a bicycle, if you want a fast vehicle get a motorcycle. And the author comes along and say, well, yeah, bicycles are not that fast, but the Snake 3000 has an alternator that uses 80% of the bike's mechanical energy to run a seat warmer, if you removed that you could reach 20mph. So is the real reason for the Snake 3000's slowness "because it is a bicycle" or "because it has a pedal-powered seat warmer"?

(The answer is both of course, but with respect to Python people rarely acknowledge the second one.)

That's a good question, I updated the post with a quick blurb on this. There may be a number of potential ways to distinguish them, so I gave the one that I was using for the blog post.

Consider a program written in Python. Imagine it converted into some "internal representation" that will be used by the interpreter to execute it.

We can ask questions like "when I write a statement in Python that adds two integers (typically a single machine instruction in a C program), how many machine instructions are executed while running that statement?"

Those are questions about the interpreter - essentially, the raw speed and execution patterns of the language.

But when you're running a Python program (or one written in many other languages these days), there is a lot going on inside the process that you cannot map back to the Python statements you wrote. The most obvious is memory management, but there are several others.

This stuff takes time to execute and can change the behavior of the statements that you did write in subtle (and not so subtle ways).

Note that this kind of issue exists even for compiled languages too: when you run a program written in C++, the compiler will have inserted varying amounts of code to manage a variety of things into the executable that do not map back explicitly to the lines you wrote. This is the "C++ runtime" at work, and even though the "C++ language" may run at essentially machine speed, the runtime still adds overhead in some places.

Interpreted languages are the same, just worse (by various metrics)

I understand the notion of a "runtime" in the compiled language case; my question is about the distinction between an interpreter and a runtime in the interpreted language case. Perhaps out of naivety, I would think that the interpreter is the runtime--the interpreter manages the call stack, memory, etc.

Well, imagine for example that you wrote this in python:

    s = "hello" + "world"

You could measure the execution of the internal representation of this, and that would be all about the speed of the interpreter.

At some point, something may have to clean up temporaries and that may happen asynchronously with respect to the actual statement execution. Yes, it happens in the same process as the interpreter's execution of the code, but it's a theoretically "optional" cost that has no specific relationship with the statement.

There are interpreters, for example, where you can disable garbage collection. If the overall execution time decreased, it's not because the interpreter got faster, it's just doing less of the "runtime" work.

So is there anything besides the GC which satisfies this definition of "runtime"? What other asynchronous activities are going on apart from those of the Python program itself?

C does not have an interpreter (well, the most used implementations don't) but often has a runtime (libc). It's really a runtime and not just a library, because a C compiler can insert calls to its functions even if they aren't part of your code at all, like here : https://gcc.godbolt.org/z/_w78qd

You're quite right - the distinction is entirely synthetic here.

If you could swap out the runtime without changing the interpreter, the distinction would be far more valid.

Reply on news.ycombinator.com