[dead]
Performance of the Python 3.14 tail-call interpreter
171–180 of 180 posts
Re: Performance of the Python 3.14 tail-call interpreter
#172Earlier quoted context omitted.
> It is very straightforward indeed, but it is still not mapping primitive > operations to direct machine code, but it is forwarding to out-of-line code. > Same as operator overloading in other languages. I am not claiming that C is a collection of assembler macros. There is no expectation that a C compiler emit machine code that has exact 1:1 correspondence with the input source code. > Same as operator overloading…
> ... and other hidden complex control flow,.... Until someone calls longjmp() or a signal() is triggered. Extra bonus of fun if it happens to be multithreaded application, or in the middle of a non-rentrant call.
Or your emulated float or atomic relies on non-local state, like a control word or a spin-lock pool.
Re: Performance of the Python 3.14 tail-call interpreter
#173Earlier quoted context omitted.
The parent example can be made clearer like this: https://godbolt.org/z/MKWbz9W16 Dead code elimination only works here because integer overflow is UB.
Take a closer look at 'eru's example and my follow-up. He wrote an example where the result of `a+1` isn't necessary, so the compiler doesn't emit an ADDI even though the literal text of the C source contains the substring "a += 1". Your version has the same issue: unsigned int square2(unsigned int num) { unsigned int a = num; a += 1; if (num The return value doesn't depend on `a+1`, so the compiler can optimize it t…
C compilers are just too smart IMO to make C portable assembly. Your example doesn’t always ADDI either, for example if it is inlined
https://godbolt.org/z/vv9rvKsxn
This isn’t qualitatively different from what the JVM JIT would do, but Java isn’t considered portable assembly.
I guess if you compile with optimizations completely off, you get something that is assembly-like, but I’ve never seen that in prod code.
Re: Performance of the Python 3.14 tail-call interpreter
#174Hello. 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…
No one cares about this oversight - more important is that you spend time on development that the rest of us don’t have (or don’t have the skill to do in my case). Thanks for your hard work.
Re: Performance of the Python 3.14 tail-call interpreter
#175Why 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.
Because they started work on Python (the compiler) in 1980!
Re: Performance of the Python 3.14 tail-call interpreter
#176I recently made some benchmarking from python 3.9 to 3.13 And up to 3.11 it only got better. Python 3.12 and 3.13 were about 10% slower than 3.11. I thought my homemade benchmark wasn't great enough so I deployed it to a core service anyway and I saw same changes in our collected metrics. Does anyone else have the same problem?
I'm also still using 3.11 for a FastAPI app since 3.12 and 3.13 are quite a bit slower.
Re: Performance of the Python 3.14 tail-call interpreter
#177Earlier quoted context omitted.
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... .
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.
Re: Performance of the Python 3.14 tail-call interpreter
#178Earlier quoted context omitted.
The parent example can be made clearer like this: https://godbolt.org/z/MKWbz9W16 Dead code elimination only works here because integer overflow is UB.
Take a closer look at 'eru's example and my follow-up. He wrote an example where the result of `a+1` isn't necessary, so the compiler doesn't emit an ADDI even though the literal text of the C source contains the substring "a += 1". Your version has the same issue: unsigned int square2(unsigned int num) { unsigned int a = num; a += 1; if (num The return value doesn't depend on `a+1`, so the compiler can optimize it t…
> He wrote an example where the result of `a+1` isn't necessary, so the compiler doesn't emit an ADDI even though the literal text of the C source contains the substring "a += 1".
No, the result of the 'a+1' is necessary in my version. And if you change the type from 'int' to 'unsigned' you will see that the compiler no longer just omits the addition.
Re: Performance of the Python 3.14 tail-call interpreter
#179Earlier quoted context omitted.
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... .
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.
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?
Re: Performance of the Python 3.14 tail-call interpreter
#180Earlier quoted context omitted.
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.
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?
> 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.