Hacker News Reader

Comment by coldtea | Hacker News Reader

>There was a question from Shannon about "what people think is a acceptable slowdown for single-threaded code". To a large extent, that question went unanswered in the thread, but he had estimated an impact "in the 15-20% range, but it could be more, depending on the impact on PEP 659".

So, let me get this straight, some of those working in the project to "make CPython faster", think it's acceptable to overnight make most existing Python code 15-20% slower?

I'd say max 5% and that if the gil removal was a benefit to other optimizations going forward (they say the opposite: the change with complicate and stall their other optimizations).

Meanwhile, Shannon had a fundraising proposal for him personally "speeding up CPython" 5x back in 2020. Now it's a whole team working on speeding up CPython with much larger corporate support, and it seems their targets are quite smaller?

View on HN

But consider that in perhaps 99% of current python code high performance (of the pure python code) is not the primary concern. And now for the times when performance does matter you can get a 20x (?) speedup without rewriting in another language.

I'd expect in many those cases people care for performance, they already use multiprocess (so the impact from a 20% hit GIL-free CPython would actually be a slowdown).

And for those that do not use multiprocess, rewriting their currently single threaded Python code for no-gil shared-concurrency will indeed bring a speedup, but would still be a significant rewrite.

Also there are people using Python for things like web serving, where performance might have been secondary to convenience when they picked Python, but still a sudden 15-20% slowdown will seriously impact their server budgets (or ability to update versions)...

> But consider that in perhaps 99% of current python code high performance (of the pure python code) is not the primary concern.

Then why do we care about GIL removal at all?

> I'd say max 5% and that if the gil removal was a benefit to other optimizations going forward

Some of the recent performance improvements came out of the no-gil camp to show that there was significant room for improvement even with the gil removed.

> (they say the opposite: the change with complicate and stall their other optimizations).

So they wont actually be stopped, it will just take them a bit longer?

"A bit" could be the better part of a decade, which is an eternity in IT time. And some wont even be possible anymore, or way more difficult, and indeed, be stopped.

I agree that the "faster CPython" project is way oversold. I have compared real world code with numerical and string operations without any network or disk accesses. 3.12-beta only uses 20-25% less time than 3.8.

That's the level of 2.7.

I seems that the old boys are desperate for some bullet point features for the next release to impress their corporate masters. So they use the work of Sam Gross, but they will slowly get the credit over time.

There's a big history of projects underfunded, overpromising, and getting tossed aside, not even halfway there, when it comes to a faster Python.

In a PL-fantasy-league they would just heavily sponsor Lars Bak to create a team and work on a new Python interpreter!

Yeah, but this project is actually delivering stuff that's been shipped. That's perhaps why it's taking a bit longer. As far as I can tell, they haven't gotten to the boxing removal stuff yet where the really big wins probably are.

As for your fantasy, we already have PyPy.

>Yeah, but this project is actually delivering stuff that's been shipped.

The initial selling point was ~ 5x speedup over 5 years.

This is over a year now, with far more people and resources plus the backling of a major industry-player (MS), and it's been like 20%-30% improvements at best, and even those in danger to be wiped out by the no-gil change.

>As for your fantasy, we already have PyPy.

That's nowhere near Lars Bak level fantasy results...

It was actually 5x in 4 years (1.5x per year).

As you said we see 20-30% at best. And several important workloads have important slowdowns (for example coveragepy runs 30-50% slower).

The GIL is an academic problem which has little real world relevance.

Reply on news.ycombinator.com