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

51–60 of 65 posts

Re: Python extensions should be lazy

#51

Post by halfcat »

rurban wrote: post #44
Spivak wrote: post #33

Earlier quoted context omitted.

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 type…

>> You're never going to have any language with the kind of dynamism that Python/Ruby/JS have while also having performant number crunching

> Wrong

Can you give examples of languages that achieve both? Or is this all just on a spectrum? Like if we say C# is performant, it’s still the case that (eventually) the way to make it faster is “stop writing C#”.

Re: Python extensions should be lazy

#52

Post by BiteCode_dev »

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.

That's literally the opposite of focusing.

Re: Python extensions should be lazy

#53

Post by sgarland »

f33d5173 wrote: post #24
tomjakubowski wrote: post #6

Earlier quoted context omitted.

re: 3, Python has a native numeric array type https://docs.python.org/3/library/array.html

array is for serializing to/from binary data. It isn't useful for returning from a library because the only way a python programmer can consume it is by converting into python objects, at which point there is no efficiency benefit. numpy has a library of functions for operating directly on the referenced data, as well as a cottage industry of libraries that will take a numpy array as input. Obviously someone might en…

multiprocessing.shared_memory.ShareableList can be useful in some circumstances, even if you don’t intend on sharing it across processes. It allows direct access to the data, elements are mutable (to an extent; you can’t increase the size of either the overall list or its elements once built), and since the underlying shm is exposed, you can get memoryviews for zero-copy.

The downside is they’re on the more esoteric side of Python, so people may not be as familiar with them as other structures.

Re: Python extensions should be lazy

#54

Post by sgarland »

lalaland1125 wrote: post #41
dumah wrote: post #29

Earlier quoted context omitted.

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.

Memoryviews abstract the buffer interface as an object, so perhaps that’s what was meant.

I disagree with the inclination to jump to numpy. I much prefer minimizing 3rd party libraries, especially if the performance is equivalent or nearly so.

Re: Python extensions should be lazy

#55

Post by sgarland »

BiteCode_dev wrote: post #52
sgarland wrote: post #46

Earlier quoted context omitted.

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.

That's literally the opposite of focusing.

What you’re describing is myopia. Focusing purely on performance at the expense of anything else would probably result in highly unreadable code, yes. Being aware of and caring about performance, and choosing to prioritize it when reasonable is not the same thing.

Re: Python extensions should be lazy

#56

Post by sgarland »

halfcat wrote: post #49
sgarland wrote: post #46

Earlier quoted context omitted.

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…

IME from the perspective of an SRE / DBRE, performance is nearly always given up (if it’s ever even considered) in favor of making things easier, and this tends to have large consequences later on.

People seem to have taken the quote, “premature optimization is the root of all evil” to mean “don’t focus on performance until you absolutely have to,” but when you push them to prove that they don’t have to, they often haven’t even profiled their code! Cloud compute – and especially K8s – has made it such that it’s expected that you simply over-provision and scale as necessary to get the throughput you need. I don’t personally see running through a profiler (ideally as part of CI) as being particularly difficult or onerous.

Re: Python extensions should be lazy

#57

Post by neonsunset »

halfcat wrote: post #51
rurban wrote: post #44

Earlier quoted context omitted.

> 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 type…

>> You're never going to have any language with the kind of dynamism that Python/Ruby/JS have while also having performant number crunching > Wrong Can you give examples of languages that achieve both? Or is this all just on a spectrum? Like if we say C# is performant, it’s still the case that (eventually) the way to make it faster is “stop writing C#”.

> Like if we say C# is performant, it’s still the case that (eventually) the way to make it faster is “stop writing C#”.

That has stopped being true a few years ago and in some cases was never true.

The way for a faster C# codebase is writing faster C#. .NET CoreLib including all performance-sensitive paths like memmove is written in pure C#, and the VM (by that I mean all reflection bits, TypeLoader, etc.) itself, excluding GC, is also pure C# when you are using NativeAOT.

The optimization techniques to achieve this are but not limited to using monomorphized struct generics, stack buffers, arenas and memory pooling, using SIMD API (which has the same performance characteristics as intrinsics in C/C++), not allocating by using structs or making object lifetime GC friendly if allocations cannot be avoided, making otherwise safe code bounds check elision friendly, reducing indirection, etc. Many of these are exact same as what you would do in languages like C, C++ or Rust.

As a result, the use of FFI to call into C/C++/Rust/ObjC/Swift(upcoming native Swift ABI support)/etc. today is predominantly relegated to accessing necessary OS APIs and libraries.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Of course most of these optimizations are at odds with "dynamism" and yield the speed-up by making the dispatch static and inlining-friendly, and giving the compiler more information it can prove and make use of. Not to mention C# (together with Swift) sits the closest to the metal among otherwise high-level languages by virtue of what .NET is and what its ILC and JIT compile IL to.

Re: Python extensions should be lazy

#58

Post by jmkr »

sgarland wrote: post #47
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.

I have thought Python's arrays have been overlooked for years. So much so that people call a list an array.

Re: Python extensions should be lazy

#59

Post by jmkr »

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 discovered memoryview when looking at the JACK Python library. It is pretty neat. But also one of those things I wouldn't have known to look for.

Re: Python extensions should be lazy

#60

Post by coldtea »

ameliaquining wrote: post #28
coldtea wrote: post #17

Earlier quoted context omitted.

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.

What kind of subset would you have in mind? I think that any kind of numeric operation would be off the table, for the reasons given in PEP 465: "Providing a quality implementation of matrix multiplication is highly non-trivial. Naive nested loop implementations are very slow and shipping such an implementation in CPython would just create a trap for users. But the alternative – providing a modern, competitive matrix…

The best they can do without BLAS. Doesn't have to be as fast as numpy, just faster and more memory efficient than doing it in native Python, without the dependency.
Post reply on HN