I wish the money could be spent on PyPy but pypy has its problems - you don't get a big boost on small programs that run often because the warmup time isn't that fabulous.
For larger programs like you sometimes it some incredibly complicated incompatibility problem. For me bitbake was one of those - could REALLY benefit from pypy but didn't work properly and I couldn't fix it.
If this works more reliably or has a faster warmup then....well it could help to fill in some gaps.
Isn’t that similar to JS? My understanding was modern JS runtimes had something like this:
interpreted -> basic JIT -> fancy JIT
The interpreter gets you going fast. The basic JIT is extremely fast to compile but not the most performant. If the code can be JITed it quickly will be.
From there the engine can find hotspots or functions that get run a lot and use the fancy JIT on them in the background. That means the slow compile doesn’t block things but when the result can be swapped in performance can take a big jump.
At any point the engine can drop down to the interpreter if an assumption is violated (someone passes a string where they had always used numbers before) or a function is redefined.
It wouldn’t surprise me if something like that appeared as an option in Python over time to get the best of both worlds.
For larger programs like you sometimes it some incredibly complicated incompatibility problem. For me bitbake was one of those - could REALLY benefit from pypy but didn't work properly and I couldn't fix it.
If this works more reliably or has a faster warmup then....well it could help to fill in some gaps.