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

Python 3.13 Gets a JIT

tonybaloney.github.io

Post reply on HN
Print view View original

381–390 of 553 posts

Re: Python 3.13 Gets a JIT

#381

Post by chalst »

hartator wrote: post #369
EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

Because it took 10 years to have Python 3 being as fast as Python 2 while being more strict. 2-9% means it will be another 10 years to have Python 3 being significantly faster. Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...

5.5% compounded over 5 years is a bit over 30%: not a huge amount but an easily noticeable speed-up. What were you thinking of when you typed “significantly faster”?

Re: Python 3.13 Gets a JIT

#382

Post by vegesm »

wrd83 wrote: post #17

Honestly I don't understand the pessimistic view here. I think every release since Microsoft started funding python has increased high single digit best case performance. Rather than focussing on the raw number compare to python 3.5 or so. It's still getting significantly faster. If they keep doing this steady pace they are slowly saving the planet!

Because it only increases high single digit each release. If they keep up the 10% improvement for the next 10 release, we will reach a speedup of around 2.5 times. That's very small, considering how Python is like 10-20 times slower than JS (not even talking about C or Java like speeds).

Re: Python 3.13 Gets a JIT

#383

Post by klyrs »

leephillips wrote: post #379
klyrs wrote: post #377

Earlier quoted context omitted.

I'm not that up to date on the language, it's been a few years since I did anything nontrivial with it because the experience was so poor. And while that might not seem fair to Julia, it's my honest experience: my concern isn't a pissing match between Julia and the world, it's that bad JIT experience is a huge turnoff and I'm worried about Python's future as it goes down this road.

There has been so much progress in Julia’s startup performance in the past “few years” that someone’s qualitative impressions from several major releases before the current one are of limited relevance.

You're making this about Julia despite my repeated statements to the contrary. Please reread what I've written, you aren't responding to the actual point I've made twice now. A reminder: I'm talking specifically about my outlook on the future of Python, vis a vis my historical experience with how other JIT languages have developed.

If you wanted to rebut this, you'd need to argue that Julia has always been awesome and that my experience with a slow warmup was atypical. But that would be a lie, right?

And, subtext: when I wrote my first commebt in this thread, its highest sibling led with

> I think the pessimism really comes from a dislike for Python

So I weighed in as a Python lover who is pessimistic for reasons other than a bias against the language.

Re: Python 3.13 Gets a JIT

#384

Post by bilsbie »

EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

Someone please compare 3.13 to 2.3! I’d love to see how far we’ve come.

Re: Python 3.13 Gets a JIT

#385

Post by bilsbie »

hartator wrote: post #369
EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

Because it took 10 years to have Python 3 being as fast as Python 2 while being more strict. 2-9% means it will be another 10 years to have Python 3 being significantly faster. Ref: https://mail.python.org/pipermail/python-dev/2016-November/1...

What! Why? (I couldn’t figure it out from your link)

Re: Python 3.13 Gets a JIT

#386

Post by bastawhiz »

Iridescent_ wrote: post #60

Wasn't CPython supposed to remain very simple in its codebase, with the heavy optimization left for other implementations to tackle? I seem to remember hearing as much a few years back.

PyPy was released 17 years ago

Jython was released 22 years ago

IronPython was released 17 years ago

To date, no Python implementation has managed to hit all three:

1. Stay compatible with any recent, modern CPython version

2. Maintain performance for general-purpose usage (it's fast enough without a warmup, and doesn't need to be heavily parallelized to see a performance benefit)

3. Stayed alive

Which, frankly, is kind of a shame. But the truth of the matter is that it was a high bar to hit in the first place, and even PyPy (which arguably had the biggest advantages: interest, mindshare, compatibility, meaningful wins) managed to barely crack a fraction of a percent of Python market share.

If you bet on other implementations being the source of performance wins, you're betting on something which essentially doesn't exist at this point.

Re: Python 3.13 Gets a JIT

#387

Post by ptx »

frankjr wrote: post #121
JodieBenitez wrote: post #61

Earlier quoted context omitted.

Have you tried to generate a SHA256 checksum for a file in the browser, no matter what crypto lib or api is available to you ? Have you tried to generate it using Python standard lib ? I did, and doing it in the browser was so bad that it was unusable. I suspect that it's not the crypto that's slow but the file reading. But anyway... > SHA256 in pure Python would be unusably slow None would do that because: > Python'…

Just for giggles I tried this and I'm getting ~200ms when reading and hashing 50MB file in the browser (Chromium based) vs ~120ms using Python 3.11.6. https://jsfiddle.net/yebdnz6x/

I thought that perhaps the difference could be due to the JavaScript version having to first read the entire file before getting started on hashing it , whereas the Python does it incrementally (which the browser API doesn't support [0]). But changing the Python version to work like the JavaScript version doesn't make a big difference: 30 vs 35 ms (with a ~50 MB file) on my machine.

The slowest part in the JavaScript version seems to be reading the file, accounting for 70–80% of the runtime in both Firefox and Chromium.

[0] https://github.com/w3c/webcrypto/issues/73

Re: Python 3.13 Gets a JIT

#388

Post by edgyquant »

onetoo wrote: post #96
mg wrote: post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

The restart isn't expensive in absolute terms, on a human level it's practically instant. You would only do this during development, hopefully your local machine isn't the production environment. It's also very easy, often just adding a CLI flag to your local run command. edit: Regarding performance, Python today can easily handle at least 1k requests per second. The vast vast vast majority of web applications today…

I hate this argument that “most web apps don’t need that kind of performance.” For one thing, with responsive apps that are the norm it wouldn’t be surprising for a session to begin with multiple requests or to even have multiple requests per second. At that point all it takes is a few hundred active users to hit that 1k limit.

But even leaving that aside, you never know when your application will be linked somewhere or go semi-viral and not being able to serve 1000 users is all it takes for your app to go down and your one shot at a successful company to die a sad death.

Re: Python 3.13 Gets a JIT

#389

Post by korijn »

nextaccountic wrote: post #376
EmilStenstrom wrote: post #332

It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!

This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)

Partly, yes, but do note he is still very much involved with the faster-cpython project via Microsoft. Google faster cpython and van rossum to find some interviews and talks. You can also check out the faster-cpython project on github to read more.

Re: Python 3.13 Gets a JIT

#390

Post by onetoo »

edgyquant wrote: post #388
onetoo wrote: post #96

Earlier quoted context omitted.

The restart isn't expensive in absolute terms, on a human level it's practically instant. You would only do this during development, hopefully your local machine isn't the production environment. It's also very easy, often just adding a CLI flag to your local run command. edit: Regarding performance, Python today can easily handle at least 1k requests per second. The vast vast vast majority of web applications today…

I hate this argument that “most web apps don’t need that kind of performance.” For one thing, with responsive apps that are the norm it wouldn’t be surprising for a session to begin with multiple requests or to even have multiple requests per second. At that point all it takes is a few hundred active users to hit that 1k limit. But even leaving that aside, you never know when your application will be linked somewhere…

I didn't say python can handle =1K. I feel confident that I am orders of magnitude off the real limit you'd meet.

The specifics of that aside, any unprepared application is going to buckle at a sudden mega-surge of users. The solution remains largely the same, regardless of technology: Make sure everything that can be cached is cached, scale the hardware vertically until it stops helping, optimize your code, scale horizontally until you run out of money. I imagine the DB will be the actual bottleneck, most of the time.

There are other reasons to not choose python for greenfield application, but performance should rarely be one IMO.

Post reply on HN