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.