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

Python extensions should be lazy

gauge.sh

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Python extensions should be lazy

#41

Post by lalaland1125 »

dumah wrote: post #29
lalaland1125 wrote: post #2

Optimizing Python extensions is becoming increasingly important as Python is used in more and more compute intensive environments. The key for optimizing a Python extension is to minimize the number of times you have to interact with Python. A couple of other tips in addition to what this article provides: 1. Object pooling is quite useful as it can significantly cut down on the number of allocations. 2. Be very care…

3. The memoryview interface is often a good solution.

I think you mean the buffer interface?

I think the buffer interface is too complex to provide directly to users. I think an API that returns numpy arrays is simpler and easier to understand.

Re: Python extensions should be lazy

#42

Post by BiteCode_dev »

coldtea wrote: post #15
raymondh wrote: post #8

This is an impressive post showing some nice investigative work that isolates a pain point and produces a performant work-around. However, the conclusion is debatable. Not everyone has this problem. Not everyone would benefit from the same solution. Sure, if your data can be loaded, manipulated, and summarized outside of Python land, then lazy object creation is a good way to go. But then you're giving up all of the…

> However, the conclusion is debatable. Not everyone has this problem. Not everyone would benefit from the same solution. Everyone would benefit from developers being more performance minded and not doing uneccesarry work though! Especially Python who has long suffered with performance issues. Love your work btw!

No. Days only 24h. If you focus on perfs, you leave something else.

Python is python because people cared about other things for many years.

Re: Python extensions should be lazy

#44

Post by rurban »

Spivak wrote: post #33
RhysU wrote: post #22

Earlier quoted context omitted.

> Optimizing Python extensions is becoming increasingly important as Python is used in more and more compute intensive environments. I have always loved how the trick to making Python better eventually comes down to not writing Python.

Is this not expected? You're never going to have any language with the kind of dynamism that Python/Ruby/JS have while also having performant number crunching simply because Python has to do more significantly more work for the same line of code. You could envision a world where a JIT could recognize cases where all that dynamism falls away and you can generate code similar to what you would get in the equivalent C b…

> You're never going to have any language with the kind of dynamism that Python/Ruby/JS have while also having performant number crunching simply because Python has to do more significantly more work for the same line of code.

Wrong. With strong types you do have ability to tell the compiler that most of the dynamic checks and hooks can be omitted, and values can stay unboxed. Python, ruby, perl choose to ignore types so far. And Javascript, PHP did at least dynamic optimizations with their type hints.

Re: Python extensions should be lazy

#45

Post by KptMarchewa »

coldtea wrote: post #17
jph00 wrote: post #13

Earlier quoted context omitted.

If you don't want to add a dep on numpy (which is a big complex module) then it's nice to have a stdlib option. So there are certainly at least some cases where you're not better off with numpy.

Even better if Python adds a mainline pandas/numpy like C-based table structure, with a very small subset of the pandas/numpy functionality, that's also convertable to pandas/numpy/etc.

It just should be native support for Apache Arrow.

Re: Python extensions should be lazy

#46

Post by sgarland »

BiteCode_dev wrote: post #42
coldtea wrote: post #15

Earlier quoted context omitted.

> However, the conclusion is debatable. Not everyone has this problem. Not everyone would benefit from the same solution. Everyone would benefit from developers being more performance minded and not doing uneccesarry work though! Especially Python who has long suffered with performance issues. Love your work btw!

No. Days only 24h. If you focus on perfs, you leave something else. Python is python because people cared about other things for many years.

You can focus on multiple things, you know. There is some low-hanging fruit in Python for performance in certain circumstances (mostly hot loops, at least, in my experiments). For example, if you need to extract a string from a datetime object, doing so manually with f-strings is about 20% faster than strftime. If you use the string mini-format language instead, it’s 40% faster.

Re: Python extensions should be lazy

#47

Post by sgarland »

lalaland1125 wrote: post #2

Optimizing Python extensions is becoming increasingly important as Python is used in more and more compute intensive environments. The key for optimizing a Python extension is to minimize the number of times you have to interact with Python. A couple of other tips in addition to what this article provides: 1. Object pooling is quite useful as it can significantly cut down on the number of allocations. 2. Be very care…

Re: 3, you can also use Python’s array.array in some circumstances. If you have heterogeneous types, don’t need multiple dimensions, and don’t need Fortran memory layout, they’re a good choice IMO, and one that doesn’t require pulling in 3rd party packages.

Re: Python extensions should be lazy

#48

Post by rbanffy »

coldtea wrote: post #16
stabbles wrote: post #5

Earlier quoted context omitted.

Why not go all the way and limit the times you have to interact with Python to zero ;)

Because then you have the warts of the new language, and the pain of migrating code, which could be 100s or millions of lines, to worry about...

People have been trying to move away from COBOL since I was a kid and I’m not even young.

Re: Python extensions should be lazy

#49

Post by halfcat »

sgarland wrote: post #46
BiteCode_dev wrote: post #42

Earlier quoted context omitted.

No. Days only 24h. If you focus on perfs, you leave something else. Python is python because people cared about other things for many years.

You can focus on multiple things, you know. There is some low-hanging fruit in Python for performance in certain circumstances (mostly hot loops, at least, in my experiments). For example, if you need to extract a string from a datetime object, doing so manually with f-strings is about 20% faster than strftime. If you use the string mini-format language instead, it’s 40% faster.

”You can focus on multiple things”

You can, but each added focus degrades the quality of the others.

The key principle is thinking with a mindset of cost.

Even if it’s low hanging fruit, there’s a world of difference between assuming we can work it in, and saying, “this is what it will cost, and this is what we won’t work on result”.

And similarly, saying ”that’s impossible” is not in the same universe as “the cost is extremely high and it’s not important enough to us to pay that cost”.

Re: Python extensions should be lazy

#50

Post by hansvm »

ameliaquining wrote: post #27
hansvm wrote: post #4

Earlier quoted context omitted.

My last workplace used pyo3 for a project. It was slower than vanilla Python, and you picked up all the normal compiled-language problems like slow builds and cross-compilation toolchains. I wouldn't take away from that observation that pyo3 is slow (it was just a poor fit; FFI for miniscule amounts of work), but the fact that the binding costs were higher than vanilla Python computations suggests that the overhead i…

I'd definitely be curious to know what specific runtime operations PyO3 inserts that you don't have to do with the C API. Naively it doesn't seem like there should be any, since Rust has zero-overhead C FFI.

Sorry, "FFI" was a shorthand for "mixing and matching two languages' GC expectations, memory layouts, ..." and all the overhead associated with merging something opinionated, like Rust, with something dynamic, like Python. You almost certainly _can_ reduce that overhead further, but unless somebody has gone out of their way to do so, the default expectation for cross-language calls like that should be that somebody opted for maintainable code that has actually shipped instead of shaving off every last theoretical bit of overhead.

It's been a few years, so I really can't tell you exactly what the problem was (other than the general observation that you should try to do nontrivial amounts of work in your python extensions rather than trivial amounts), but PyO3 agrees with the general sentiment [0] [1], or at least did at roughly the same time I was working there.

[0] https://github.com/PyO3/pyo3/issues/679

[1] https://github.com/PyO3/pyo3/issues/1470

Post reply on HN