LWN: Comments on "Faster CPython at PyCon, part one"

Faster CPython at PyCon, part one

massimiliano — Mon, 15 May 2023 10:07:27 +0000

If you want to see state-of-the-art dynamic opcode specialization look at what V8 (the Chrome Javascript VM) has been doing for more than one decade :-)

Faster CPython at PyCon, part one

gps — Fri, 12 May 2023 19:03:09 +0000

When continual invariant checking would be overwhelming, another approach is commonly used: assume invariants are true but record all state changes in a way that can be undone. So you proceed with some execution and do the invariant check before any point that would force you to commit and expose your state change to the broader system in a way that cannot be rolled back. In the rare case those invariant checks fail, you back out all uncommitted state changes from that piece of execution and take the slow invariant handling path. If it fails often, you flag that bit of code and don't run such a state assuming aggressive JIT translation on that part in the future.

I don't know how feasible this approach is for a high level language, but it has been implemented time and time again in JIT/translation-like systems over the past several decades.

We did this in Transmeta's CMS (code morphing software) that implemented x86, but that was obviously much lower level and on hardware designed for the purpose.

Faster CPython at PyCon, part one

Wol — Fri, 12 May 2023 07:23:14 +0000

I doubt they'll go down this road, but ...

Interpreted VM code is also known as p-code, no? And I know of at least two CPUs that were designed (Pascal) or modified (50-series) to execute p-code directly :-)

Isn't that also pretty much a description of CRISC systems?

Cheers,
Wol

Faster CPython at PyCon, part one

ebwb — Fri, 12 May 2023 05:26:26 +0000

I always feel delighted when I see it. Sometimes it's nice to have a bit of feedback from a different, perhaps atypical channel as to where my funding helps support LWN's work.

Maybe they literally mean to thank you, me, and all of us! Surely there are some conferences the individual LWN staff members wouldn't be able to attend were it not for their work, so they are expressing gratitude for the fact that we're all here making it happen for those individuals.

Faster CPython at PyCon, part one

anton — Thu, 11 May 2023 17:24:35 +0000

One step between interpreted virtual-machine (VM) code and native code ("emmitting asm") is dynamic superinstructions (aka selective inlining). Combining this with quickening is non-trivial, but possible. Having multiple alternative quickened superinstructions, and switching back to the slow variant, and then to a different quickened superinstruction is not covered in that paper, but I think it's possible.

Faster CPython at PyCon, part one

kpfleming — Thu, 11 May 2023 11:56:28 +0000

Except in Python the 'emitted asm' still has to check that the necessary invariants have not changed; dynamic languages make this much more difficult than otherwise. At some point if the 'invariant checking' code is large enough, inlining it in every location where the JIT has turned the code into 'emitted asm' will have its own costs (memory pressure, caching, etc.)

Faster CPython at PyCon, part one

jake — Thu, 11 May 2023 00:15:29 +0000

> You're welcome. That's why we support LWN, to cover its expenses and provide its staff with an
> income. That is all pretty obvious. So why did you feel the need to add this to this article?

We put those on articles in part to remind others, who may not be subscribers, that it does cost money to do all of this stuff. And of course to thank folks like you.

FWIW, we do generally get free tickets to conferences, either because we are speaking or because we ask for a press pass (as with PyCon). Press passes are pretty normal for tech (and other) journalism. We presumably could not go to as many conferences without them.

jake

Faster CPython at PyCon, part one

kleptog — Wed, 10 May 2023 21:48:46 +0000

I first heard of this trick of specialising opcodes with respect to the Erlang VM. The interesting thing is that this is a step in the direction of a JIT. Namely, once you can recognise that all the instructions in a loop are specialised versions, it's but a small step to emitting asm code directly.

Faster CPython at PyCon, part one

pebolle — Wed, 10 May 2023 21:43:48 +0000

> Possibly this is written in this way so that it can be shown that this wasn't a cost-free attendance funded by the conference giver in return for a favourable review.

Yes, that's a murky area. I'm not sure what to think here. Is it OK for the press to accept free entrance to expensive conferences?

But the disclaimer only mentioned travel, which I think is a pretty obvious expense for LWN. Actually, I'm totally OK with whatever LWN decides to spend our contributions on. Free champagne and caviar for its staff? Fine with me.

Faster CPython at PyCon, part one

pebolle — Wed, 10 May 2023 21:31:44 +0000

> IRC this was prompted by questions from readers before on whether sponsorship is involved and in some cases, the answer is yes.

But apparently no sponsorship was involved. So why bother with this message here?
Otherwise every article might end with:

[I would like to thank LWN subscribers for funding the device I've written this article on and the purchase of literature I consulted while researching this article.]

Yes, we know. That's why we support you.

Faster CPython at PyCon, part one

rahulsundaram — Wed, 10 May 2023 21:15:12 +0000

> You're welcome. That's why we support LWN, to cover its expenses and provide its staff with an income. That is all pretty obvious. So why did you feel the need to add this to this article?

It looks like it is done to distinguish it from articles written where some other entity is sponsoring the travel. As an example, https://lwn.net/Articles/637211/ has this note instead:

[I would like to thank the Linux Foundation for travel support to Boston for the summit.]

IIRC this was prompted by questions from readers before on whether sponsorship is involved and in some cases, the answer is yes.

Faster CPython at PyCon, part one

amacater — Wed, 10 May 2023 21:12:16 +0000

Possibly this is written in this way so that it can be shown that this wasn't a cost-free attendance funded by the conference giver in return for a favourable review.

Faster CPython at PyCon, part one

pebolle — Wed, 10 May 2023 20:26:14 +0000

> [I would like to thank LWN subscribers for supporting my travel to Salt Lake City for PyCon.]

You're welcome. That's why we support LWN, to cover its expenses and provide its staff with an income. That is all pretty obvious. So why did you feel the need to add this to this article?

Faster CPython at PyCon, part one

Wol — Wed, 10 May 2023 13:22:23 +0000

> That gives you current "master" compared to 3.11

Is that "Python for Workgroups"?

(G, d & r)

Cheers,
Wol

Faster CPython at PyCon, part one

Twirrim — Wed, 10 May 2023 13:04:07 +0000

Not precisely yet, but https://speed.python.org/comparison/ can help you compare against latest branch of master

https://speed.python.org/comparison/?exe=12%2BL%2B3.11%2C... is my best attempt to do comparisons. That gives you current "master" compared to 3.11, using normalised against the latter.

Faster CPython at PyCon, part one

jpfrancois — Wed, 10 May 2023 08:50:15 +0000

Are there any benchmark number available that would illustrate these performance improvements for 3.11 and 3.12 ?

Faster CPython at PyCon, part one

dureuill — Wed, 10 May 2023 06:43:30 +0000

To my knowledge it doesn't: type annotations are not used at runtime. Plus, nothing at runtime prevents a user from calling such an annotated function with the wrong types anyway.

Faster CPython at PyCon, part one

tchernobog — Wed, 10 May 2023 06:37:08 +0000

Does anybody know if specifying type annotations such as floats are able to skip the adaptive instructions and go to their specialized counterparts directly?