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

151–160 of 180 posts

Re: Performance of the Python 3.14 tail-call interpreter

#151

Post by eru »

jmillikin wrote: post #83
vikramkr wrote: post #78

Earlier quoted context omitted.

I'm pretty sure that's replying directly to the comment about how c is close to assembly and that if you add that line of code somewhere you know there's a variable getting incremented. Doesn't really matter whether or not it's useful, the point is that the behavior isn't exactly what you wrote

To reiterate, claiming that C can be described as "portable assembly" is not a claim that it is literally a package of assembler macros that emit deterministic machine code for each individual source expression. I linked these in another comment, but here's some examples of straightforward-looking integer addition emitting more complex compiler output for other languages that compile to native code: Haskell: https://…

The Haskell version deals with both laziness and also detects overflow.

Your C++ example has a lot more code than the C example, I'm not sure why you'd expect it to produce the same output?

Re: Performance of the Python 3.14 tail-call interpreter

#152

Post by eru »

mkoubaa wrote: post #60
WJW wrote: post #28

Earlier quoted context omitted.

C might be low level from the perspective of other systems languages, but that is like calling Apollo 11 simple from the perspective of modern spacecraft. C as written is not all that close to what actually gets executed. For a small example, there are many compilers who would absolutely skip incrementing 'a' in the following code: uint32_t add_and_subtract_1(uint32_t a) { a += 1; a -= 1; return a; } Even though that…

If you want the compiler to treat your code as literal portable assembly turn off optimizations.

That's a property of a particular compiler, not of the C language (at least as described in the standard).

Re: Performance of the Python 3.14 tail-call interpreter

#153

Post by eru »

jmillikin wrote: post #38
tux3 wrote: post #22

Earlier quoted context omitted.

You show one example where C doesn't have problems, but that's a much weaker claim than it sounds. "Here's one situation where this here gun won't blow your foot off!" For what it's worth, C++ also passes your test here. You picked an example so simple that it's not very interesting.

'eru implied `a += 1` has undefined behavior; I provided a trivial counter-example. If you'd like longer examples of C code that performs unsigned integer addition then the internet has many on offer. I'm not claiming that C (or C++) is without problems. I wrote code in them for ~20 years and that was more than enough; there's a reason I use Rust for all my new low-level projects. In this case, writing C without unde…

Yes, 'a += 1' can have undefined behaviour in C when you use signed integers. (And perhaps also with floats? I don't remember.)

Your original comment didn't specify that you want to talk about unsigned integers only.

Re: Performance of the Python 3.14 tail-call interpreter

#154

Post by eru »

jmillikin wrote: post #103
gpderetta wrote: post #88

Earlier quoted context omitted.

In what world the return value doesn't depends on 'a' in this code? if (num A control dependency is still a dependency

`a = num; a += 1; if (num If the code returns `num * a` then the value of `a` is now necessary, and must be computed before the function returns. For signed integer addition the compiler is allowed to assume that `(num < (num + 1))` is true, so the comparison can be removed entirely.

> For signed integer addition the compiler is allowed to assume that `(num That's not directly what the compiler assumes. The direct problem is in 'a + 1' having undefined behaviour, and that transitively allows the assumption on the comparison that you mentioned.

This was an example where 'a + 1' doesn't compile to an add instruction.

Re: Performance of the Python 3.14 tail-call interpreter

#156

Post by ses1984 »

acdha wrote: post #77
johnisgood wrote: post #59

Earlier quoted context omitted.

Why would you want it to increment 1 if we decrement 1 from the same variable? That would be a waste of cycles and a good compiler knows how to optimize it out, or what am I misunderstanding here? What do you expect "it" to do and what does it really do? See: https://news.ycombinator.com/item?id=43320495

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.

Re: Performance of the Python 3.14 tail-call interpreter

#157

Post by kenjin4096 »

haberman wrote: post #121
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…

I think it's important to note that a primary motivation of the tail call interpreter design is to be less vulnerable to the whims of the optimizer. From my original blog article about this technique ( https://blog.reverberate.org/2021/04/21/musttail-efficient-i... ): > Theoretically, this control flow graph paired with a profile should give the compiler all of the information it needs to generate the most optimal co…

This is a good point. We already observed this in our LTO and PGO builds for the computed goto interpreter. On modern compilers, each LTO+PGO build has huge variance (1-2%) for the CPython interpreter. On macOS, we already saw a huge regression in performance because Xcode just decided to stop making LTO and PGO work properly on the interpreter. Presumably, the tail call interpreter would be immune to this.

Re: Performance of the Python 3.14 tail-call interpreter

#158

Post by nickm12 »

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 undervalued. Being able to say that you and your team should have investigated a too-good-to-be-true result further before reporting it is setting a higher standard for yourselves.

But another way to read this is "no need to feel bad" and on this I agree. We all often fail to sufficiently challenge our own work, especially when it looks like something we worked hard on had a big impact.

Re: Performance of the Python 3.14 tail-call interpreter

#160

Post by ltbarcly3 »

I think it's remarkable that nobody thought to benchmark against a independent build, maybe from debian or redhat. I do this for my local builds I use for development even, it's just so absurdly obvious (and not just in hindsight).

No real harm was done but some embarrassment, but it's pretty silly.

Post reply on HN