So it seems I was wrong, [[msvc::musttail]] is documented! I will update the blog post to reflect that.

https://news.ycombinator.com/item?id=46385526

Important enough, or benefits them directly? I have no good guesses how improving Python's performance would benefit them, but I would guess that's the real reason.

[flagged]

[flagged]

Thanks :), that was indeed my intention. I think the previous 3.14 mistake was actually a good one on hindsight, because if I didn't publicize our work early, I wouldn't have caught the attention of Nelson. Nelson also probably wouldn't have spent one month digging into the Clang 19 bug. This also meant the bug wouldn't have been caught in the betas, and might've been out with the actual release, which would have been way worse. So this was all a happy accident on hindsight that I'm grateful for as it means overall CPython still benefited!

Also this time, I'm pretty confident because there are two perf improvements here: the dispatch logic, and the inlining. MSVC can actually convert switch-case interpreters to threaded code automatically if some conditions are met [1]. However, it does not seem to do that for the current CPython interpreter. In this case, I suspect the CPython interpreter loop is just too complicated to meet those conditions. The key point also that we would be relying on MSVC again to do its magic, but this tail calling approach gives more control to the writers of the C code. The inlining is pretty much impossible to convince MSVC to do except with `__forceinline` or changing things to use macros [2]. However, we don't just mark every function as forceinline in CPython as it might negatively affect other compilers.

[1]: https://github.com/faster-cpython/ideas/issues/183 [2]: https://github.com/python/cpython/issues/121263

I’ll repeat what I said at that time: one of the benefits of the new design is that it’s less vulnerable to the whims of the optimizer: https://news.ycombinator.com/item?id=43322451

If getting the optimal code is relying on getting a pile of heuristics to go in your favor, you’re more vulnerable to the possibility that someday the heuristics will go the other way. Tail duplication is what we want in case, but it’s possible that a future version of the compiler could decide that it’s not desired because of the increased code size.

With the new design, the Python interpreter can express the desired shape of the machine code more directly, leaving it less vulnerable to the whims of the optimizer.

> (wish it's a link in the article)

I've asked Ken. He said he'll update the article.

I really like the Python + Qt/pyside combination. I can whip together a rough GUI using QtCreator and then write the app logic in Python super quickly.

Depending on how important the GUI is to you, I would look into LINQPad for stuff that is scripting but too heavy.

If anyone stumbles upon this in a search for Python UI libaries, also check out Textural. It's a TUI setup that can also be displayed in web browsers because it uses CSS for styling. At least for fairly uncomplicated UIs, it seems pretty simple, and has good event hook support. It has some features like event bubbling, and reactivity, which smack of JS front-end framework workflows on the data side, for better or worse.

Wait until you see ImGui bindings for Python [1]. It’s immediate mode instead of retained mode like Tkinter/Qt/Wx. It might not be what you’d want if you’re shipping a thick client to customers, but for internal tooling it’s awesome.

    imgui.text(f"Counter = {counter}")
    if imgui.button("increment counter"):
        counter += 1

    _, name = imgui.input_text("Your name?", name)
    imgui.text(f"Hello {name}!")

Look at pyfltk also. I haven't used the windows builds, but it's real nice on GNU/Linux.

Well, using MAUI instead of Avalonia or Uno was the mistake.

Quite to the contrary, I'd say this update is evidence of the inner loop being hyperoptimized!

MSVC's support for musttail is hot off the press:

> The [[msvc::musttail]] attribute, introduced in MSVC Build Tools version 14.50, is an experimental x64-only Microsoft-specific attribute that enforces tail-call optimization. [1]

MSVC Build Tools version 14.50 was released last month, and it only took a few weeks for the CPython crew to turn that around into a performance improvement.

[1] https://learn.microsoft.com/en-us/cpp/cpp/attributes?view=ms...

Python’s goal is never really to be fast. If that were its goal, it would’ve had a JIT long ago instead of toying with optimizing the interpreter. Guido prioritized code simplicity over speed. A lot of speed improvements including the JIT (PEP 744 – JIT Compilation) came about after he stepped down.

Software has gotten so slow we've forgotten how fast computers are

This is (a) wildly over expectations for open source and (b) a massive pain to maintain, and (c) not even the biggest timewaster of python, which is the packaging "system".

I remember a former colleague, (may he RIP) ported a similar optimization to our fork of Python 2.5, circa 2007. We were running Linux on PPC and it gave us that similar 10-15% boost at the time.

If you want fast just use pypy and forget about cpython.

Probably because anyone concerned with performance wasn’t running workloads on Windows to begin with.

I know of a couple reasons offhand.

JavaScript is JIT’ed where CPython is not. Pypy has JIT and is faster, but I think is incompatible with C extensions.

I think Pythons threading model also adds complexity to optimizing where JavaScripts single thread is easier to optimize.

I would also say there’s generally less impetus to optimize CPython. At least until WASM, JavaScript was sort of stuck with the performance the interpreter had. Python had more off-ramps. You could use pypy for more pure Python stuff, or offload computationally heavy stuff to a C extension.

I think there are some language differences that make JavaScript easier to optimize, but I’m not super qualified to speak on that.

> why is pyhton interpreter so much slower than V8 javascript interpreter when both javascript and python are dynamic interpreted languages.

Because JS’s centrality to the web and V8’s speed’s centrality to Google’s push to avoid other platform owners controlling the web via platform-default browsers meant virtually unlimited resources were spent in optimizing V8 at a time when the JS language itself was basically static; Python has never had the same level of investment and has always spent some of its smaller resources on advancing the language rather than optimizing the implementation.

Also, because the JS legacy that needed to be supported through that is pure JS, whereas with CPython there is also a considerable ecosystem of code that deeply integrates with Python from the outside that must still be supported, and the interface used by that code limits the optimizations that can be applied. Faster Python interpreters exist that don’t support that external ecosystem, but they are less used because that ecosystem is a big part of Python’s value proposition.

I can think of two possible reasons:

First is the Google's manpower. Google somehow succeeds in writing fast software. Most Google products I use are fast in contrast to the rest of the ecosystem. It's possible that Google simply did a better job.

The second is CPython legacy. There are faster implementations of Python that completely implement the API (PyPy comes to mind), but there's a huge ecosystem of C extensions written with CPython bindings, which make it virtually impossible to break compatibility. It is possible that this legacy prevents many possible optimizations. On the other hand, V8 only needs to keep compatibility on code-level, which allows them to practically switch out the whole inside in incremental search for a faster version.

I might be wrong, so take what I said with a grain of salt.

keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript.

Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution.

Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how freely the internals can be changed (see the bug-by-bug compatibility work done for example by pypy, just to name an example, with some constraint that limit some optimizations)

Python is much, much more dynamic. E.g. look at how something as basic as accessing an attribute on an object works: https://docs.python.org/3/howto/descriptor.html

Also Python has a de facto stable(ish) C ABI for extensions that is 1) heavily used by popular libraries, and 2) makes life more difficult for the JIT because the native code has all the same expressive power wrt Python objects, but JIT can't do code analysis to ensure that it doesn't use it.

Even though Javascript is quite dynamic, Python is much worse. Basically everything involves a runtime look-up. It's pretty much the language you'd design if you were trying to make it as slow as possible.

[dead]

Are you referring to the violin plot? https://en.wikipedia.org/wiki/Violin_plot and in Matplotlib as https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot....

It's in essence a histogram for the distribution, with smoothing, and mirrored on each side.

It looks nice, but is not without well-deserved opposition because 1) the use of smoothing can hide the actual distribution, 2) mirroring contains no extra information, while taking up space, and implying the extra space contains information, and 3) when shown vertically, too often causes people to exclaim it looks like a vulva.

In an HN discussion on the topic, medstrom at https://news.ycombinator.com/item?id=40766519 points to a half-violin plot at https://miro.medium.com/v2/1*J3Q4JKXa9WwJHtNaXRu-kQ.jpeg with the histogram on the left, and the half-violin on the right, which gives you a chance to see side-by-side presentation of the same data.

I would have thought it actually helps the branch target predictor rather than the branch predictor. If you assume a simple predictor where the predicted target is just the last taken one then it's going to be wrong almost every time for a single switch. It will only be right for repeats of the exact same instruction.

If you have a separate switch at the end of each instruction then it will be right any time an instruction is followed by the same instruction as last time, which can probably happen quite a lot for short loops.

Is this backed by real evidence?

Imagine how much fast those Windows and XBox games would be if they used gcc/clang. /s

I think in the protobuf example the musttail did in fact benefit from better register use. All the functions are called with the same arguments, so there is no need to shuffle the registers. The same six register-passed arguments are reused from one function to the next.

Does MSVC support computed goto?

If you want to make your writing appear non-AI generated, the easiest way is to write it yourself. No typos necessary.

I’m sure with enough cajoling you can make the LLM spit out a technical blog post that isn’t discernibly slop - wanton emoji usage, clichés, self-aggrandizement, relentlessly chipper tone, short “punchy” paragraphs, an absence of depth, “it’s not just X—it’s a completely new Y” - but it must be at least a little tricky what with how often people don’t bother.

[ChatGPT, insert a complaint about how people need to ram LLMs into every discussion no matter how irrelevant here.]

Woops, thanks for noticing, fixed!

Yup, but 5 to 15% faster year on year is real progress and that's ultimately what the big user base of Python are counting on at this point.. and they seem to be getting it! Full disclaimer: I'm not a heavy Python user exactly due to the performance and build/distribution situation - it's just sad from a user-end perspective (I'm not addressing centralised web deployment here but rather decentralised distribution which I ultimately find more "real" and rewarding).

Thanks for reading! For now, we maintain all 3 of the interpreters in CPython. We don't plan to remove the other interpreters anytime soon, probably never. If MSVC breaks the tail calling interpreter, we'll just go back to building and distributing the switch-case interpreter. Windows binaries will be slower again, but such is life :(.

Also the interpreter loop's dispatch is autogenerated and can be selected via configure flags. So there's almost no additional maintenance overhead. The main burden is the MSVC-specific changes we needed to get this working (amounting to a few hundred lines of code).

> Impact on debugging/profiling

I don't think there should be any, at least for Windows. Though I can't say for certain.

Profile of llm generated comments

They find them useful as a performance optimization, not as a design tool. This optimization is not relevant to Python code because it relies on the optimization passes the compiler makes.

Got it. I'll try to set one up this weekend.

You'd be surprised at how little speedup you get from simply JIT-compiling the Python bytecode. It's so high-level that most interesting stuff happens in the layers below anyway.