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

How fast can we make interpreted Python?

phi-node.com

Post reply on HN
Print view View original

51–60 of 83 posts

Re: How fast can we make interpreted Python?

#51

Post by xenonflash »

I don't think its correct to say the CPython is slow. What you can more accurately say about CPython is that the performance is highly variable. Some things are very fast, while others are comparatively slow.

The slow things tend to be the sort of numerical loops that you see in micro-benchmarks. It's no coincidence that the version of Python in the linked article saw its greatest speed up in a numerical loop, but only modest improvement elsewhere. It's exactly this sort of simple repetitive operation where interpreter overhead matters the most.

Language features that encapsulate complex functionality tend to be harder to speed up in CPython because the VM operates at a fairly high level. In effect you're just kicking off a large subroutine that is written in C, and you're really executing native code until that operation is complete. You're not going to improve very much on that no matter how much you try.

What this means is that speed will depend heavily on the type of application program being written, and also on how much the programmer takes advantage of the unique language features. It also makes realistic cross language benchmarks difficult because the right way to do something in Python may not have a direct equivalent in another language. The result tends to be "lowest common denominator" benchmarks, which are exactly the sort of algorithms which CPython does worst at.

Re: How fast can we make interpreted Python?

#52

Post by nostrademons »

fijal wrote: post #50
nostrademons wrote: post #45

Earlier quoted context omitted.

The last time I talked with the Unladen Swallow guys (a couple years ago), they were pretty clear that one of their main stumbling blocks was supporting the Python/C API, and wanting to have complete compatibility with C extension modules. While we can't really know how hard the task would've been if they'd lifted that requirement - it was baked into their design from an early stage - when I'd floated the idea of doi…

They were optimistic at the beginning too (even with C extensions). How would it fill your usecase in a way that pypy does not?

We were looking for something easily embeddable, but all host modules were provided by the application, so there was no need for outside C extensions. And the set of libraries that was importable was restricted and coding styleguides banned advanced language features like metaprogramming, so we could afford to cut corners on corner cases of the language. "Decent" performance (i.e. more like Java than CPython) was a requirement, as was multithreading support and lack of a GIL, and RAM usage was also at a premium (which was probably the largest argument against PyPy...also, this was a couple years ago, when PyPy was not as mature).

Re: How fast can we make interpreted Python?

#53

Post by simonh »

mappu wrote: post #41

This is bikeshedding, but "The only hard problems in computer science are cache invalidation and naming things" - there's already a quite popular, multi-paradigm programming language named Falcon[1]. 1. http://www.falconpl.org/

Sorry, but the two hard problems in programming are actually cache invalidation, naming things and off by one errors.

Re: How fast can we make interpreted Python?

#54

Post by lmm »

Fomite wrote: post #49
freework wrote: post #8

Python is typically used to build applications that are IO bound. Squeezing more performance out of the interpreter is not going to translate to any real gains for most Python users these days.

I'm sure this will come as a surprise to everyone using Python's rather well developed scientific computing stack.

You mean the one that's implemented mostly in FORTRAN with python as a mere coordinating layer on top?

(And don't get me wrong, it's an effective approach that plays to the strengths of both languages. But it's not doing "heavy lifting" in python)

Re: How fast can we make interpreted Python?

#55

Post by lmm »

gizmo686 wrote: post #35
sherjilozair wrote: post #28

Earlier quoted context omitted.

2) Need "speed" - write that part in C.) That's not so easy. Interfacing Python and C code is also incredibly hard, and no one true way exists.

>That's not so easy. Interfacing Python and C code is also incredibly hard, and no one true way exists. Can you elaborate on this. I've worked on python C extensions (just minor updates and fixes, I've never been the one to write significant chunks of it), and it seems like interfacing python with C is pretty straight forward.

If you use the CPython C API it's easy - but you also bind yourself closely to CPython. If you know performance is going to be important it's probably better to bite the bullet and use PyPy - which means you have to use the somewhat cruder cffi to interface with C code.

Re: How fast can we make interpreted Python?

#56

Post by bjourne »

jerf wrote: post #15

It seems to me over the past ten years I've heard this story so many times: "Python sucks. Let's do the obvious thing that makes it faster." Then, a month or two later, "I did the obvious thing and it's sometimes faster but often slower, net no gain or possible loss." to which the response is obviously "No sale." I say this merely as an interesting observation. I've come to consider this a de facto counterargument to…

Pythons byte code interpreter loop is very tight. As previously mentioned, it's a simple stack-based vm with a small instruction set. The upshot to that is that is that it is very short, meaning that the executable is very small, meaning that most of it fits in the cpu cache.

Cache misses are incredibly expensive, and any "obvious optimization" of Python's core will inevitably introduce more of them because the code gets longer. So most of the optimizations wins big in the area in which they are targeted, but loses in general performance.

For the same reason gcc -Os (optimizing for small binary) is often faster than gcc -O3.

On top of that, there is significant resistance from the devs to complicate the core. They prefer a slower, but easier to understand, easier to analyze interpreter over a complex one with harder to predict runtime performance. It's the same with reference counting and theoretically superior garbage collection.

Re: How fast can we make interpreted Python?

#57

Post by int3 »

Interesting approach. One criticism: The paper mentions that compile times max out at 1.1ms "for the most complex function" in the benchmark (AES), and therefore it is sufficient to just compile everything. However, those benchmarks seem too small to justify that conclusion.

Re: How fast can we make interpreted Python?

#58

Post by shaurz »

gregorsamza wrote: post #5
bsimpson wrote: post #4

As a web developer, I've often heard neckbeards bickering about Python's performance, but haven't had a real point-of-reference to understand how bad it can be until recently. I've started working on a side project that processes geo data in AppEngine. My dataset includes many long lists of numbers (lats, longs, altitudes, timestamps, etc.). A 700 route dataset is about 25MB in a sqlite database, but trying to access…

A dataset with "many long lists of numbers" sounds like an ideal use case for NumPy, have you tried using that?

Or even simply the array module.

Re: How fast can we make interpreted Python?

#59

Post by PommeDeTerre »

bsimpson wrote: post #4

As a web developer, I've often heard neckbeards bickering about Python's performance, but haven't had a real point-of-reference to understand how bad it can be until recently. I've started working on a side project that processes geo data in AppEngine. My dataset includes many long lists of numbers (lats, longs, altitudes, timestamps, etc.). A 700 route dataset is about 25MB in a sqlite database, but trying to access…

Did the person from Google that you talked to happen to mention an issue number in Python's tracker, or anything of that sort?

Something seems very wrong if every 1 MB of data read from your SQLite database ends up consuming 150+ MB of memory in some way.

Are you able to provide any sample code and a SQLite database that exhibit this problem, so attempts can be made to fix it?

Re: How fast can we make interpreted Python?

#60

Post by maxerickson »

bsimpson wrote: post #47
gregorsamza wrote: post #5

Earlier quoted context omitted.

A dataset with "many long lists of numbers" sounds like an ideal use case for NumPy, have you tried using that?

I haven't. I don't have any complex math in mind (yet), just some simple transformations. The problem is that even something as simple as checking a list for potential duplicates becomes really RAM intensive for sufficiently large lists. (I'm not even doing deep equality, just comparing metadata.) I still have plenty more work to do on the project. I think I'll end up fanning out each list iteration into a series of…

Numpy supports lots of array math, but another way to think of it is as an api for working directly with memory (and values stored as platform types instead of python objects).

(Which you may well realize...)

Post reply on HN