On: Performance of the Python 3.14 tail-call interpreter

[vikramkr]

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

[jmillikin → vikramkr]

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://godbolt.org/z/vdeMKMETT

C++: https://godbolt.org/z/dedcof9x5

[eru → jmillikin]

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?

[johnisgood → vikramkr]

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.

[eru → johnisgood]

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

[johnisgood → eru]

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....

[eru → johnisgood]

The C standard guarantees certain behaviours that will not change, even if your C compiler changes. That's the whole point of the standard. And it has nothing to do with the problem of induction.

But the standard does not guarantee that specific assembly instructions will be used.

[johnisgood → eru]

Sure, but what programming language or its standard guarantees it (and its compilers in practice, of course), then?

You said "Your compiler might change tomorrow.", but does it not apply to EVERY programming language's compiler?

[eru → johnisgood]

> You said "Your compiler might change tomorrow.", but does it not apply to EVERY programming language's compiler?

Yes. I wasn't the one trying to argue that C is special in this regard. Just the opposite.