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

Performance of the Python 3.14 tail-call interpreter

blog.nelhage.com

Post reply on HN
Print view View original

161–170 of 180 posts

Re: Performance of the Python 3.14 tail-call interpreter

#161

Post by remexre »

ses1984 wrote: post #156
acdha wrote: post #77

Earlier quoted context omitted.

That’s a contrived example but in a serious program there would often be code in between or some level of indirection (e.g. one of those values is a lookup, a macro express, or the result of another function). Nothing about that is cheating, it just says that even C programmers cannot expect to look at the compiled code and see a direct mapping from their source code. Your ability to reason about what’s actually exec…

What optimizer would remove the increment/decrement if the value was accessed in between? That seems like something that would be really easy to detect. I’ve never studied compilers though.

It would be very normal for a compiler to do an increment (or merge it into a later instruction), but never do the decrement, and instead use the old copy of the value.

Re: Performance of the Python 3.14 tail-call interpreter

#162

Post by ltfish »

twoodfin wrote: post #149
ehsankia wrote: post #126

Earlier quoted context omitted.

I guess the bigger question for me is, how was a 10% drop in Python performance not detected when that faulty compiler feature was pushed? Do we not benchmark the compilers themselves? Do the existing benchmarks on the compiler or python side not use that specific compiler?

The author makes this point, too, and I agree it’s the most surprising thing about the entire scenario. LLVM introduced a major CPython performance regression, and nobody noticed for six months?

As far as I am aware, the official CPython binaries on Linux have always been built using GCC, so you will have to build your own CPython using both Clang 18 and 19 to notice the speed difference. I think this is partly why no one has noticed the speed difference yet.

Re: Performance of the Python 3.14 tail-call interpreter

#163

Post by throwaway2037 »

nickm12 wrote: post #158
kenjin4096 wrote: post #51

Hello. I'm the author of the PR that landed the tail-calling interpreter in CPython. First, I want to say thank you to Nelson for spending almost a month to get to the root of this issue. Secondly, I want to say I'm extremely embarrassed and sorry that I made such a huge oversight. I, and probably the rest of the CPython team did not expect the compiler we were using for the baseline to have that bug. I posted an apo…

Thank you for your efforts in improving Python and especially thank you for helping to set the record straight in such a clear and visible manner. Some of the sibling comments are saying there's "no need to apologize". One way this might be read is "no need to hold yourself to a higher standard". If this is the sentiment, then I disagree—we live in an age where accountability and intellectual integrity are undervalue…

    > we live in an age where accountability and intellectual integrity are undervalued
I'm tired of this doomerism trope on HN. One thing has been constant in my life: People complaining that "we live in an age where accountability and intellectual integrity are undervalued". For me, it is on the same level as interviewing people for a local news show: "So, how's traffic these days?" "Oh, it's never been worse."

In what age were accountability and intellectual integrity "correctly" valued?

Re: Performance of the Python 3.14 tail-call interpreter

#164

Post by throwaway2037 »

coldtea wrote: post #82
kenjin4096 wrote: post #65

Earlier quoted context omitted.

That's a fair question. The blog post mentions it brings a 1-5% perf improvement. Which is still significant for CPython. It does not complicate the source because we use a DSL to generate CPython's interpreters. So the only complexity is in autogenerated code, which is usually meant for machine consumption anyways. The other benefit (for us maintainers I guess), is that it compiles way faster and is more debuggable…

There was a plan for a 5x speedup overall looking for funding back in 2022. Then a team with Guido and others involved (and MS backing?) got on the same bandwagon and made some announcements for speeding up CPython a lot. Several releases in, have we seen even a 2x speedup? Or more like 0.2x at best? Not trying to dismiss the interpreter changes - more want to know if those speedup plans were even remotely realistic,…

Original details here: https://github.com/markshannon/faster-cpython/blob/master/pl...

About the author: https://us.pycon.org/2023/speaker/profile/81/index.html

    > His academic and commercial work is focused on compilers, virtual machines and static analysis for Python. His PhD was on building virtual machines for dynamic languages.
This dude looks God-level.

Half-joking: Maybe MSFT can also poach Lars Bak of Google V8-fame.

Re: Performance of the Python 3.14 tail-call interpreter

#165

Post by throwaway2037 »

MattPalmer1086 wrote: post #9

Benchmarking is just insanely hard to do well. There are so many things which can mislead you. I recently discovered a way to make an algorithm about 15% faster. At least, that's what all the benchmarks said. At some point I duplicated the faster function in my test harness, but did not call the faster version, just the original slower one... And it was still 15% faster. So code that never executed sped up the origin…

Aleksey Shipilёv, a long-time Java "performance engineer" (my term) has written and spoken extensively about the challenging of benchmarking. I highly recommend to read some of his blog posts or watch one of his talks about it.

Re: Performance of the Python 3.14 tail-call interpreter

#166

Post by jraph »

rtollert wrote: post #146
jraph wrote: post #71

Earlier quoted context omitted.

Reading that you are extremely embarrassed and sorry that you made such a huge oversight, I was imagining you had broken something / worsened CPython's performance. But it's nothing like this. You announced a 10-15% perf improvement but that improvement is more like 1-5% on a non buggy compiler. It's not even like that 10-15% figure is wrong , it's just that it's correct only under very specific conditions, unknowing…

> IIUC, you did your homework: you made an improvement, you measured a 10-15% perf improvement, the PR was reviewed by other people, etc. It just so happens that this 10-15% figure is misleading because of an issue with the version of clang you happened to use to measure. Unless I'm missing something, it looks like a fair mistake anyone could have reasonably made. It even looks like it was hard to not fall into this…

Could very well be!

Interesting, I didn't know about the Gettier problem, thanks for sharing. You could try submitting that page as a proper HN post.

Re: Performance of the Python 3.14 tail-call interpreter

#167

Post by thdhhghgbhy »

kenjin4096 wrote: post #51

Hello. I'm the author of the PR that landed the tail-calling interpreter in CPython. First, I want to say thank you to Nelson for spending almost a month to get to the root of this issue. Secondly, I want to say I'm extremely embarrassed and sorry that I made such a huge oversight. I, and probably the rest of the CPython team did not expect the compiler we were using for the baseline to have that bug. I posted an apo…

Don't apologise. Programming is about the process not the person.

Re: Performance of the Python 3.14 tail-call interpreter

#168

Post by johnisgood »

eru wrote: post #150
johnisgood wrote: post #94

Earlier quoted context omitted.

https://godbolt.org/z/r39jK1ddv It increments, then decrements with -O0 though. I do not see the issue still, as the behavior is expected with -O0; increments then decrements.

There's nothing in the C standard that enforces the observed -O0 behaviour. Your compiler might change tomorrow.

How likely is that to happen, and in which languages can you either optimize or not AND where the compiler might not change tomorrow though?

David Hume said that we cannot know if the sun is going to rise tomorrow just because it has always did before. See "problem of induction", https://philosophynow.org/issues/160/Humes_Problem_of_Induct....

Re: Performance of the Python 3.14 tail-call interpreter

#169

Post by WJW »

remexre wrote: post #161
ses1984 wrote: post #156

Earlier quoted context omitted.

What optimizer would remove the increment/decrement if the value was accessed in between? That seems like something that would be really easy to detect. I’ve never studied compilers though.

It would be very normal for a compiler to do an increment (or merge it into a later instruction), but never do the decrement, and instead use the old copy of the value.

Then in the next step, it would see that the result of the increment is never used and thus the increment instruction is dead code and can also be removed.

Re: Performance of the Python 3.14 tail-call interpreter

#170

Post by gjvc »

ltbarcly3 wrote: post #159

Why hasn't anyone just carbon copied the Python compiler (coincidentally the same name but unrelated to the Python language) from SBCL? The semantics of CL aren't that different from Python (the language).

The compiler is named Python, but has nothing to do with Python the language. I mean __really__. Way to keep your invention buried.
Post reply on HN