|
|
Subscribe / Log in / New account

Faster CPython at PyCon, part one

Faster CPython at PyCon, part one

Posted May 12, 2023 19:03 UTC (Fri) by gps (subscriber, #45638)
In reply to: Faster CPython at PyCon, part one by kpfleming
Parent article: Faster CPython at PyCon, part one

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.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds