Hacker News Reader

Comment by mananaysiempre | Hacker News Reader

The money shot (wish this were included in the blog post):

  #   if defined(_MSC_VER) && !defined(__clang__)
  #      define Py_MUSTTAIL [[msvc::musttail]]
  #      define Py_PRESERVE_NONE_CC __preserve_none
  #   else
  #       define Py_MUSTTAIL __attribute__((musttail))
  #       define Py_PRESERVE_NONE_CC __attribute__((preserve_none))
  #   endif

https://github.com/python/cpython/pull/143068/files#diff-45b...

Apparently(?) this also needs to be attached to the function declarator and does not work as a function specifier: `static void *__preserve_none slowpath();` and not `__preserve_none static void *slowpath();` (unlike GCC attribute syntax, which tends to be fairly gung-ho about this sort of thing, sometimes with confusing results).

Yay to getting undocumented MSVC features disclosed if Microsoft thinks you’re important enough :/

View on HN

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.

I wonder if this is related to Python in Excel. You'll have lots of people running numerical stuff written in Python, running on Microsoft servers.

A lot of commercial engineering and scientific software runs on windows.

I guess there are some Python workloads on Azure, Microsoft provides a lot of data analysis and LLM tools as a service (not paid by CPU minutes). Saving CPU cycles there directly translates to financial savings.

Think about how much effort they have put into things like Pylance and general python support in VAC. Clearly they think they have enough users that this matters to that a first class experience is worth having.

Microsoft was the one hiring Guido out of retirement, and alongside Facebook finally kicking off the CPython JIT efforts.

Python is one of the Microsoft blessed languages on their devblogs.

The project was first suggested by Mark Shannon. Van Rossum inserted himself into the project. Faster CPython people have been fired by Microsoft last year.

Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat.

I think the project started in 3.10, so 3.9 is the last version to compare to. The improvements aren't that great, I don't think any other language would get so much positive feedback for so little.

I know what happened last year, my point was the prior history that lead to that effort.

https://thenewstack.io/guido-van-rossums-ambitious-plans-for...

Agree with the sentiment, Python is the only dynamic language where it seems a graveyard from efforts.

And nope it isn't the dynamism per se, Smalltalk, Self, Common Lisp are just as dynamic, with lots of possibilities to reboot the world and mess up JIT efforts, as any change impacts the whole image.

Naturally those don't have internals exposed to C where anything goes, and the culture C libraries are seen as the language libraries.

Ehh, PHP fits that bill and is clearly optimizable. All sorts of things worked well for PHP, including the original HipHop, HHVM, my own work, and the mainline PHP runtime.

Python has some semantics and behaviors that are particularly hostile to optimization, but as the Faster Python and related efforts have suggested, the main challenge is full compatibility including extensions plus the historical desire for a simple implementation within CPython.

There are limits to retrofitting truly high performance to any of these languages. You want enough static, optional, or gradual typing to make it fast enough in the common case. That's why you also saw the V8 folks give up and make Dart, the Facebook ones made Hack, etc. It's telling that none of those gained truly broad adoption though. Performance isn't all that matters, especially once you have an established codebase and ecosystem.

> Performance isn't all that matters, especially once you have an established codebase and ecosystem.

And this is no small part of why Java and JS have frequently been pushing VM performance forward — there’s enough code people very much care about continuing to work on performance. (Though the two care about different things mostly: Java cares much more about long-term performance, and JS cares much more about short-term performance.)

It doesn’t hurt they’re both languages which are relatively static compared with e.g. Python, either.

> you also saw the V8 folks give up and make Dart

V8 still got substantially faster after the first team left to do Dart. A lot of runtime optimizations (think object model optimizations), several new compilers, and a lot of GC work.

It's a huge investment to make a dynamic language go as fast as JS these days.

> It's a huge investment to make a dynamic language go as fast as JS these days.

Yes, and on the other hand, other language implementations like CPython can learn from everything people figured out for JS.

> Generally not that much has happened in 5 years, sometimes 10-15% improvements are posted that are later offset by bloat.

Sorry but unless your workload is some C API numpy number cruncher that just does matmuls on the CPU, that's probably false.

In 3.11 alone, CPython sped up by around 25% over 3.10 on pyperformance for x86-64 Ubuntu. https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-fas...

3.14 is 35-45% faster than CPython 3.10 for pyperformance x86-64 Ubuntu https://github.com/faster-cpython/benchmarking-public

These speedups have been verified by external projects. For example, a Python MLIR compiler that I follow has found a geometric mean 36% speedup moving from CPython 3.10 to 3.11 (page 49 of https://github.com/EdmundGoodman/masters-project-report)

Another academic benchmark here observed an around 1.8x speedup on their benchmark suite for 3.13 vs 3.10 https://youtu.be/03DswsNUBdQ?t=145

CPython 3.11 sped up enough that PyPy in comparison looks slightly slower. I don't know if anyone still remembers this: but back in the CPython 3.9 days, PyPy had over 4x speedup over CPython on the PyPy benchmark suite, now it's 2.8 on their website https://speed.pypy.org/ for 3.11.

Yes CPython is still slow, but it's getting faster :).

Disclaimer: I'm just a volunteer, not an employee of Microsoft, so I don't have a perf report to answer to. This is just my biased opinion.

As a data point, running a Python program I've been working on lately, which is near enough entirely Python code, with a bit of I/O: (a prototype for some code I'll ultimately be writing in a lower-level language)

(macOS Ventura, x64)

- System python 3.9.6: 26.80s user 0.27s system 99% cpu 27.285 total

- MacPorts python 3.9.25: 23.83s user 0.32s system 98% cpu 24.396 total

- MacPorts python 3.13.11: 15.17s user 0.28s system 98% cpu 15.675 total

- MacPorts python 3.14.2: 15.31s user 0.32s system 98% cpu 15.893 total

Wish I'd thought to try this test sooner now. (I generally haven't bothered with Python upgrades much, on the basis that the best version will be the one that's easiest to install, or, better yet, is there already. I'm quite used to the language and stdlib as the are, and I've just assumed the performance will still be as limited as it always has been...!)

I have a benchmark program I use, a solution to day 5 of the 2017 advent of code, which is all python and negligible I/O. It still runs 8.8x faster on pypy than on python 3.14:

    $ hyperfine "mise exec python@pypy3.11 -- python e.py" "mise exec python@3.9 -- python e.py" "mise exec python@3.11 -- python e.py" "mise exec python@3.14 -- python e.py"
    Benchmark 1: mise exec python@pypy3.11 -- python e.py
      Time (mean ± σ):     148.1 ms ±   1.8 ms    [User: 132.3 ms, System: 17.5 ms]
      Range (min … max):   146.7 ms … 154.7 ms    19 runs

    Benchmark 2: mise exec python@3.9 -- python e.py
      Time (mean ± σ):      1.933 s ±  0.007 s    [User: 1.913 s, System: 0.023 s]
      Range (min … max):    1.925 s …  1.948 s    10 runs
     
    Benchmark 3: mise exec python@3.11 -- python e.py
      Time (mean ± σ):      1.375 s ±  0.011 s    [User: 1.356 s, System: 0.022 s]
      Range (min … max):    1.366 s …  1.403 s    10 runs
     
    Benchmark 4: mise exec python@3.14 -- python e.py
      Time (mean ± σ):      1.302 s ±  0.003 s    [User: 1.284 s, System: 0.022 s]
      Range (min … max):    1.298 s …  1.307 s    10 runs
     
    Summary
      mise exec python@pypy3.11 -- python e.py ran
        8.79 ± 0.11 times faster than mise exec python@3.14 -- python e.py
        9.28 ± 0.13 times faster than mise exec python@3.11 -- python e.py
       13.05 ± 0.16 times faster than mise exec python@3.9 -- python e.py

https://gist.github.com/llimllib/0eda0b96f345932dc0abc2432ab...

> [...] and I've just assumed the performance will still be as limited as it always has been...!)

Historically CPython performance has been so bad, that massive speedups were quite possible, once someone seriously got into it.

And indeed that has proven the case. But my assumption was that Python had been so obviously designed with performance so very much not in mind, that it had ended up in some local minimum from which meaningful escape would be impossible. But I didn't overthink this opinion, and I've always liked Python well enough for small programs anyway, so I don't mind having it proven wrong.

How to stay employed for life: create a programming language which is pretty good, but with some fatal flaws (GIL, typing, slow) and you are set for life.

I don’t know about calling them fatal, but inculcating a culture that believes the flaws are inescapable laws of reality is probably key.

+ It is also blessed by PowerBI and recently, Excel.

Reply on news.ycombinator.com