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

State of Python 3.13 performance: Free-threading

codspeed.io

Post reply on HN
Print view View original

81–90 of 193 posts

Re: State of Python 3.13 performance: Free-threading

#81

Post by wruza »

dagmx wrote: post #65
wruza wrote: post #36

Earlier quoted context omitted.

Could you point to any specific major breaking changes between 3.x releases? I can not, but I can tell you that anything AI often requires finding a proper combination of python + cuXXX + some library. And while I understand cu-implications, for some reason python version is also in this formula. I literally have four python versions installed and removed from PATH, because if I delete 3.9-3.11, they will be needed n…

Those are ABI changes and not changes to the language.

If these were just ABI changes, packagers would simply re-package under a new ABI. Instead they specify ranges of versions in which "it works". The upper end often doesn't include the last python version and may be specified as "up to 3.x.y" even.

Sure I'm not that knowledgeable in this topic (in python). But you're telling me they go to the lengths of supporting e.g. 3.9-3.11.2, but out of lazyness won't just compile it to 3.12?

I can only hypothesize that 3.9-3.xxx had the same ABI and they don't support multiple ABIs out of principle, but that sounds like a very strange idea.

Re: State of Python 3.13 performance: Free-threading

#82

Post by artemisart »

rowanG077 wrote: post #10
eigenspace wrote: post #8

Earlier quoted context omitted.

PyPy is still slow compared to actual fast languages. It's just fast compared to Python, and it achieves that speed by not being compatible with most of the Python ecosystem. Seems like a lose-lose to me. (which is presumably why it never caught on)

What isn't compatible with PyPy? I can run large frameworks using pypy no problem. There certainly will be package that aren't compatible. But far and away most of the ecosystem is fully comaptible.

This depends a lot on your domain, e.g. pypy is not compatible with pytorch or tensorflow so DL is out of the picture.

Re: State of Python 3.13 performance: Free-threading

#83

Post by JodieBenitez »

adamc wrote: post #45
eigenspace wrote: post #38

Earlier quoted context omitted.

There are ways to design languages to be dynamic while still being friendly to optimizing compilers. Typically what you want to do is promise that various things are dynamic, but then static within a single compilation context. julia is a great example of a highly dynamic language which is still able to compile complicated programs to C-equivalent machine code. An older (and less performant but still quite fast) exam…

Not disputing it, but people don't pick Python because they need the fastest language, they pick it for friendly syntax and extensive and well-supported libraries. I loved Lisp, but none of the lisps have anything like Python's ecology. Julia, even less so. People don't pick languages for language features, mostly. They pick them for their ecosystems -- the quality of libraries, compiler/runtime support, the network…

I think that to a certain extent the quality of libraries can depend on language features.

Re: State of Python 3.13 performance: Free-threading

#84

Post by dataflow »

andai wrote: post #24
eigenspace wrote: post #3

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "re…

There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experi…

> Python 2 code running on Python 3 by just changing print to print().

This was very much the opposite of my experience. Consider yourself lucky.

Re: State of Python 3.13 performance: Free-threading

#85

Post by devjab »

epistasis wrote: post #55
klysm wrote: post #31

Earlier quoted context omitted.

So pin your deps? Language backwards compatibility and an API from some random package changing are completely distinct.

Pinning deps is discouraged by years of Python practice. And going back to a an old project and finding versions that work, a year or more later, might be nigh on impossible. Last week I was trying to install snakemake via Conda, and couldn't find any way to satisfy dependencies at all, so it's not just pypi, and pip tends to be one of the more forgiving version dependency managers. It's not just Python, trying to ge…

I’m curious as to which packages you are unable to find older versions for. You mention snakemake, but that doesn’t seem to have any sort of issues.

https://pypi.org/project/snakemake/#history

Re: State of Python 3.13 performance: Free-threading

#86

Post by heisenzombie »

eigenspace wrote: post #43
dbsmith83 wrote: post #33

Earlier quoted context omitted.

There have been many breaking changes throughout python 3.x releases: - standard library modules removed - zip error handling behaves differently - changes to collections module - new reserved keywords (async, await, etc.) You can argue how big of a deal it is or isn't, but there were definitely breakages that violate semantic versioning

They removed entire standard library modules? Wut.

Yes, e.g. https://peps.python.org/pep-0594/

Re: State of Python 3.13 performance: Free-threading

#87

Post by cma »

eigenspace wrote: post #3

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "re…

How about when there are 128-256 core consumer CPUs?

Re: State of Python 3.13 performance: Free-threading

#88

Post by nomel »

klysm wrote: post #31
andai wrote: post #24

Earlier quoted context omitted.

There was a discussion the other day about how Python devs apparently don't care enough for backwards compatibility. I pointed out that I've often gotten Python 2 code running on Python 3 by just changing print to print(). But then a few hours later, I tried running a very small project I wrote last year and it turned out that a bunch of my dependencies had changed their APIs. I've had similar (and much worse) experi…

So pin your deps? Language backwards compatibility and an API from some random package changing are completely distinct.

> So pin your deps?

Which is, fairly often, pinning your python version.

Re: State of Python 3.13 performance: Free-threading

#89

Post by qaq »

adamc wrote: post #35
eigenspace wrote: post #30

Earlier quoted context omitted.

> Why does python have to be slow? Because the language's semantics promise that a bunch of insane stuff can happen at any time during the running of a program, including but not limited to the fields of classes changing at any time. Furthermore, they promise that their integers are aribtrary precision which are fundamentally slower to do operations with than fixed precision machine integers, etc. The list of stuff l…

There are different definitions of slow, though. You might want arbitrary precision numbers but want it to be reasonable fast in that context. I don't agree that it is "insane stuff", but I agree that Python is not where you go if you need super fast execution. It can be a great solution for "hack together something in a day that is correct, but maybe not fast", though. There are a lot of situations where that is, by…

"hack together something in a day" JPM Athena trading platform had 35 million lines of code in 2019 with about 20k commits a week

Re: State of Python 3.13 performance: Free-threading

#90

Post by devjab »

the__alchemist wrote: post #6
eigenspace wrote: post #3

I don't really have a dog in this race as I don't use Python much, but this sort of thing always seemed to be of questionable utility to me. Python is never really going to be 'fast' no matter what is done to it because its semantics make most important optimizations impossible, so high performance "python" is actually going to always rely on restricted subsets of the language that don't actually match language's "re…

This is a good question, and I think about it as well. My best guess for a simple explanation: Python is very popular; it makes sense to improve performance for python users, given many do not wish to learn to use a more performant language, or to use a more performant Python implementation. Becoming proficient in a range of tools so you can use the right one for the right job is high enough friction that it is not t…

You should really add that Python is also a very good tool for people who know more performant languages. I think one of the sides which often gets forgotten is that a lot of software will never actually need to be very performant and often you’re not going to know the bottlenecks beforehand. If you even get to the bottlenecks it means you’ve succeeded enough to get to the bottlenecks. Somewhere you might not have gotten if you over engineered things before you needed it.

What makes Python brilliant is that it’s easy to deliver on business needs. It’s easy to include people who aren’t actually software engineers but can write Python to do their stuff. It’s easy to make that Wild West code sane. Most importantly, however, it’s extremely easy to replace parts of your Python code with something like C (or Zig).

So even if you know performant languages, you can still use Python for most things and then as glue for heavy computation.

Now I may have made it sound like I think Python is brilliant so I’d like to add that I actually think it’s absolute trash. Loveable trash.

Post reply on HN