Hacker News Reader

Comment by reubenmorais | Hacker News Reader

10x is about what you'd expect for the interpreter overhead in a simple snippet like that.

Unfortunately python doesn't use a tagged pointers optimization even though I believe pointers are always aligned so there are some spare bits that could be used to indicate pointer vs. int.

I think the only reason they haven't is the legacy C interface; it's a shame they didn't do it for Python 3, but I guess it could have delayed conversion of c libraries even more.

Specifically, an interpreter without JIT. I'd reckon that LuaJIT or Javascript could come much closer to C.

For me, running their sample script using the PyPy JIT resulted in a 12x speedup compared to cpython.

Though that still wasn't as fast as gcc on my system (core i5 3.4ghz; using 1e8 rounds):

* cpython 2.7.4 - 1.131s

* pypy 2.6.0 - 0.090s

* gcc w/ "-O2" - 0.050s

Right, those are usually called JIT compilers, not interpreters.

The distinction is not all that useful, and is blurred nowadays. You could say that CPython compiles code to bytecode, but the bytecode is then interpreted; however, none of that matters, because it's doing very little optimization and that means it's slow. Javascript is typically also not compiled ahead-of-time to native code, but it can still be very fast because of JIT; at the same time it's still very much a dynamic language which makes it share features with interpreted languages.

I'd say JIT is neither about compilation nor interpretation, but about optimization.

Reply on news.ycombinator.com