5 ms·

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

• andreasvc 11y ago
  Specifically, an interpreter without JIT. I'd reckon that LuaJIT or Javascript could come much closer to C.
  • reubenmorais 11y ago
    Right, those are usually called JIT compilers, not interpreters.
    • andreasvc 11y ago
      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.
      • deleted 11y ago
        [deleted]
  • warbiscuit 11y ago
    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
• cma 11y ago
  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.