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

121–130 of 156 posts

Re: Why Python Is Slow: Looking Under the Hood

#121

Post by keypusher »

madengr wrote: post #80

Please forgive my ignorance, but why can't Python just be compiled into assembly like C? The compiler should be able sift through the code and see that "x=1" is an integer, or converts to a float when "x=x+1.0". If I'm doing something like counting from 1 to 10 and summing the count, why can't this be compiled to run the same speed as C? Obviously since it's interpreted, but when I'm done with development, why can't…

Write a function. It accepts two variables. Add them both together and return the result. What type is returned?

Read input from a file or stdin. Eval that input. What type does it return?

Etc.

Re: Why Python Is Slow: Looking Under the Hood

#122

Post by seunosewa »

barsonme wrote: post #97
jimbokun wrote: post #88

Earlier quoted context omitted.

What you describe is pretty much what functional languages with strong static typing, like Haskell, Scala, and Ocaml do. Works very well for examples like you gave: "x = 1", "x = x + 1.0". For expressions similar to these, inferring the types (int, float) works very well. But things get much more complex very fast, and then the compiler requires the programmer to tell it what types things are. Then there is the appro…

If Python had the same amount of time and energy put into it that JavaScript does from Google and Mozilla it'd be willing to bet it'd be a lot faster.

Like PyPy?

Re: Why Python Is Slow: Looking Under the Hood

#123

Post by [deleted] »

haberman wrote: post #34
andreyf wrote: post #26

Earlier quoted context omitted.

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…

[deleted]

Re: Why Python Is Slow: Looking Under the Hood

#124

Post by pjmlp »

rurban wrote: post #95

Unfortunately this blog post is misleading and uninformed. Python and the related other slow dynamic languages perl, php, and ruby are slow not because the dynamic type checks, branches and indirections are costly, but because they are badly written. They are just inefficient and poor interpreters, with bad ops and data structures. In comparison efficient dynamic languages like lisp, scheme, lua or javascript and man…

It seems learning about compiler design is not as good as it used to be.

Better learn about the JavaScript framework of the day.

Re: Why Python Is Slow: Looking Under the Hood

#125

Post by pjmlp »

plikan13 wrote: post #89
madengr wrote: post #80

Please forgive my ignorance, but why can't Python just be compiled into assembly like C? The compiler should be able sift through the code and see that "x=1" is an integer, or converts to a float when "x=x+1.0". If I'm doing something like counting from 1 to 10 and summing the count, why can't this be compiled to run the same speed as C? Obviously since it's interpreted, but when I'm done with development, why can't…

Why can't a C++ compiler optimize away virtual function tables? If a C++ compiler could deduce the exact derived type of all objects at compile time, it could call the correct virtual function statically instead of going through the extra indirection at runtime.

It can, but not across dynamic libraries.

You just need to use profile guided optimisation.

Re: Why Python Is Slow: Looking Under the Hood

#126

Post by nostrademons »

Animats wrote: post #64
dagw wrote: post #43

Earlier quoted context omitted.

Is it just me who sees a large chunk of these as flaws in the Python implementation as opposed to the Python language? There are a number of design decision in python language that makes it inherently hard to write a fast python implementation.

Ah, the right answer! There are lots of languages where variables are dynamically typed that can be compiled and optimized with a JIT compiler. In Python, though, any code can mess with any data, using "setattr". You can find all the variables in another module and mess with them at run time, using their names as strings. At compile time, the compiler can't detect that's going to happen. This is sometimes called the…

Google ended up developing Go because C++ was too hard to use, not because Python was too slow. The initial target market for Go was C++ programmers - it's only once it was exposed to the Internet that they found out there were more Python programmers interested in a faster Python than C++ programmers interested in an easier C++.

Re: Why Python Is Slow: Looking Under the Hood

#127

Post by coolsunglasses »

tome wrote: post #31
coolsunglasses wrote: post #28

Earlier quoted context omitted.

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.

Indeed.

I like the tricky one they're kicking around that would make `lens` faster. Pretty intriguing. I'm hopeful they'll be able to make it work in STG.

Re: Why Python Is Slow: Looking Under the Hood

#128

Post by lispm »

rurban wrote: post #95

Unfortunately this blog post is misleading and uninformed. Python and the related other slow dynamic languages perl, php, and ruby are slow not because the dynamic type checks, branches and indirections are costly, but because they are badly written. They are just inefficient and poor interpreters, with bad ops and data structures. In comparison efficient dynamic languages like lisp, scheme, lua or javascript and man…

I think the paper is even worse, in that it spreads confusion about what an Interpreter for a programming language actually is, what it does and what it provides.

The paper fails to define the concept of what to call an Interpreter. A bytecode interpreter is entirely different from a Lisp interpreter, which actually runs from source structures. Mixing VMs into the picture makes it only worse.

Part of the reason may be that they don't understand what an Interpreter actually provides and why it is used.

Re: Why Python Is Slow: Looking Under the Hood

#129

Post by albertzeyer »

csirac2 wrote: post #91
cleaver wrote: post #77

Earlier quoted context omitted.

For a general-purpose problem, Perl won't be particularly fast. For a Perl-type problem (scanning and parsing big files), Perl is very fast. Doing a Perl-type problem in a general-purpose language would be considerably slower. However, Python or others will perform much better in the "can I read my own code six months later" benchmark.

I don't know why I always have to chip in on "perl is unreadable lol" comments, but over the last 8 years apart from a steady trickle of C coding here and there the bulk of my dayjob has moved around from C/Verilog, then I discovered Ruby, then Perl/R/Python, to full-time Python now. It's true that unsupervised, weak coders using perl turn out worse code than in other languages. But it really doesn't take much to pro…

Python 3 has function annotations and you can use it for static type checks. See this:

http://www.infoq.com/news/2014/08/python-type-annotation-pro...

https://mail.python.org/pipermail/python-ideas/2014-August/0...

http://mypy-lang.org/

https://docs.python.org/3/tutorial/controlflow.html#function...

Re: Why Python Is Slow: Looking Under the Hood

#130

Post by dagw »

JoeAltmaier wrote: post #98
dragonwriter wrote: post #96

Earlier quoted context omitted.

> The compiler should be able sift through the code and see that "x=1" is an integer, or converts to a float when "x=x+1.0". The short version is "no, it shouldn't". The longer version is that, viewing Python's runtime class memberships as "types", the type system it would represent is not one for which inference without explicit declarations is generally decidable, so an AOT compiler for unmodified, unrestricted Pyt…

Its hard to be worse than an interpreter. 100X slower than compiled code is typical. Whatever 'metadata and indirection' your C target has, it seems likely to be 10X better than interpreted, easily.

Cython is a very mature python-to-C translator and it offers 0-40% speed improvements in my experience on straight Python. To get any significant speedups you have to add type declarations, replace python function with equivalent C functions from the standard library, turn off bounds checking and bunch of similar things. But if you do that then it does produce some pretty fast code.
Post reply on HN