Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Python Is Slow: Looking Under the Hood

jakevdp.github.io

Post reply on HN
Print view View original

31–40 of 156 posts

Re: Why Python Is Slow: Looking Under the Hood

#31

Post by tome »

coolsunglasses wrote: post #28
Skunkleton wrote: post #24

Another reason python is slower than other languages is that abstraction adds significant overhead which most implementations cannot optimize away. See here: http://blog.reverberate.org/2014/10/the-overhead-of-abstract...

The overhead of abstraction...unless you're using Haskell where typeclass instances get specialized, so you can abstract without slowing things down.

Let's not overstate the case. There's still plenty of abstraction which is tricky or impossible for GHC to optimize. But yes, with static analysis comes the possibility of nice optimizations.

Re: Why Python Is Slow: Looking Under the Hood

#34

Post by haberman »

andreyf wrote: post #26
jeffreyrogers wrote: post #17

Earlier quoted context omitted.

There are three primary methods of running code: interpretation, compilation to object code, and running on a VM/JIT. Obviously python is interpreted by any meaningful definition of interpretation and thus it is not compiled in the typically sense of the word (at least not in the implementation everyone uses). The reason human language is so expressive is because we can leave out a lot of context and formalism that i…

FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter, but it's definitely interpreting byte code, not the source directly. This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g. wha…

> This is very different from Perl, where a line of code isn't parseable until you know the values of the variables

Perl is crazy, but I don't think it's that crazy.

From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html)

    Perl has always had a compiler: your source is compiled
    into an internal form (a parse tree) which is then optimized
    before being run.
If what you say is true, it would not be possible to produce a parse tree prior to running the program.

I could not get your code sample to die based on the type/value of "whatever" -- can you?

Re: Why Python Is Slow: Looking Under the Hood

#35

Post by tenfingers »

tjradcliffe wrote: post #27

A related question is: why is Perl so fast? Quite a few years ago I wrote a little Runge-Kutta solver in Perl for some simulation work. It seemed like a good idea at the time. The equations of motion had to be integrated over a very long time, and it could take hours for a single run (still much faster than the Monte Carlo it was being used to do a sanity-check on). I re-wrote everything in C++, and picked up less th…

Also had the same experiences. Perl is relatively fast and memory compact compared to other modern scripting languages.

Perl also has PDL (http://pdl.perl.org/), which is very similar in scope to numpy, but predates it by several years.

Re: Why Python Is Slow: Looking Under the Hood

#36

Post by nkurz »

_wmd wrote: post #13
j_baker wrote: post #11

Earlier quoted context omitted.

When the GP talks about "small integers", I'm assuming he's talking about numbers between -5 and 256, which are cached ahead of time. They're never going to be garbage collected, so refcounting is largely unnecessary.

Once again, you can't implement this without specializing every call site that invokes Py_INCREF or Py_DECREF, or in other words, "1 conditional branch per object access everywhere."

You are right, but cost is probably very low. The conditionality of the branch doesn't matter if it's correctly predicted. On a modern processor, a correctly predicted branch-not-taken is usually indistinguishable from free unless you're already front-end constrained, which is rare for an interpreter. A correctly predicted branch-taken costs the same as a unconditional branch.

This is essentially why a JIT can be almost as fast as compiled code even when including the necessary guards. It's only when the branches become unpredictable that the costs become real. The trick with fast interpreted code is threading the execution so that the hardware is able to predict the branches accurately, but this is largely independent of the number of conditional branches.

Re: Why Python Is Slow: Looking Under the Hood

#37

Post by haberman »

tjradcliffe wrote: post #27

A related question is: why is Perl so fast? Quite a few years ago I wrote a little Runge-Kutta solver in Perl for some simulation work. It seemed like a good idea at the time. The equations of motion had to be integrated over a very long time, and it could take hours for a single run (still much faster than the Monte Carlo it was being used to do a sanity-check on). I re-wrote everything in C++, and picked up less th…

I'm not sure your results are typical.

In microbenchmarks, Perl is 2-125x slower than C++: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

And Java is quite a bit faster than Perl too: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Perl isn't really that fast. It's faster than Python in most cases, but gets beat by Lua pretty consistently: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Re: Why Python Is Slow: Looking Under the Hood

#38

Post by twoodfin »

andreyf wrote: post #26
jeffreyrogers wrote: post #17

Earlier quoted context omitted.

There are three primary methods of running code: interpretation, compilation to object code, and running on a VM/JIT. Obviously python is interpreted by any meaningful definition of interpretation and thus it is not compiled in the typically sense of the word (at least not in the implementation everyone uses). The reason human language is so expressive is because we can leave out a lot of context and formalism that i…

FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter, but it's definitely interpreting byte code, not the source directly. This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g. wha…

FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter...

Because CPython implements its virtual machine with an interpreter, without the option of, say, a JIT compiler.

Re: Why Python Is Slow: Looking Under the Hood

#39

Post by TheLoneWolfling »

Is it just me who sees a large chunk of these as flaws in the Python implementation as opposed to the Python language?

Dynamic typing can often be optimized at the compilation stage - and yes, Python has a compilation stage - this particular example is basic type inference, for example. Even more complex examples can be optimized by emitting specialized versions for the types that the compiler can see it will be called with. Effectively emitting specialized versions of specific nodes in the control flow graph.

Re: Why Python Is Slow: Looking Under the Hood

#40

Post by scott_s »

Even if you're already familiar with all of the main reasons that answer the question (that is, you're already familiar with how a VM works), read the Just for fun: a few "never use these" hacks. I mean, wow. That's the kind of nastiness I normally associate with C's free-for-all memory model.
Post reply on HN