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

61–65 of 65 posts

Re: Python extensions should be lazy

#61

Post by coldtea »

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.

>If you focus on perfs, you leave something else

That's the second benefit of focus on perfs.

We could do with less, better tested, and faster, features in most apps I know of.

Re: Python extensions should be lazy

#62

Post by coldtea »

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…

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

Only if the same people do both.

Or if dev that would rather focus on perf find it equaly motivating and fun to work on something else instead.

Re: Python extensions should be lazy

#63

Post by halfcat »

neonsunset wrote: post #57
halfcat wrote: post #51

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 > 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, e…

So, no examples? :)

That’s my gut feeling, that writing fast C# basically ends up looking like C++/Rust/etc where the niceties of C# are no longer present.

Which is the same as rewriting Python in cython. It’s way faster, and it doesn’t look like Python, or have the benefits of Python, and now just looks like weird C.

Re: Python extensions should be lazy

#64

Post by neonsunset »

halfcat wrote: post #63
neonsunset wrote: post #57

Earlier quoted context omitted.

> 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, e…

So, no examples? :) That’s my gut feeling, that writing fast C# basically ends up looking like C++/Rust/etc where the niceties of C# are no longer present. Which is the same as rewriting Python in cython. It’s way faster, and it doesn’t look like Python, or have the benefits of Python, and now just looks like weird C.

Most common optimization path is simply removing the junk and making the code drastically simpler, using appropriate CoreLib APIs and similar. A C family language that looks like other C family languages, very surprising.

Is there something specific you would like to see an example for?

Re: Python extensions should be lazy

#65

Post by ameliaquining »

hansvm wrote: post #50
ameliaquining wrote: post #27

Earlier quoted context omitted.

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

You'd also run into this if you wrote your native extension in C, right?
Post reply on HN