json-parser-in-typescript-very-bad-idea-please-dont-use VS ideas

[1]: https://github.com/jamiebuilds/json-parser-in-typescript-ver...

Also, shoutout to this guy who implemented a json parser in typescript types. This is what gave me the idea.

The next examples get progressively more bonkers, so I'm not going to write down all my thinking about them - you should check them out though and see if you can see how they work. The JSON parser is probably the best mix of complex and readable.

Lower latency native calls in Python would be extremely useful, thank you for your work! Is the following GitHub issue the right place to monitor progress? https://github.com/faster-cpython/ideas/issues/546

I'm open to doing some benchmarking. Several of my libraries have pure CPython bindings (StringZilla, UCall, SimSIMD), and all perform low-latency SIMD-accelerated ops, so might be a good testing ground :)

Recent CPython development has been towards optimizations and addressing use cases that benefit from optimizations, some coming from the faster CPython initiative. You might just get your JIT[1].

[1] https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....

The faster-cpython folks seem to be working towards a JIT (https://github.com/faster-cpython/ideas/tree/main/3.13) and both pyston and cinder have JITs. So I don't think anyone has ruled one out.

faster-cpython team has done a lot of work to experiment on it: https://github.com/faster-cpython/ideas/issues/485#issuecomm...

It kind of sounds like migration to register based is a foregone conclusion, but it's not very clear to me.

lots of big ideas are still remaining to be done. One example is the register based interpreter, see https://github.com/faster-cpython/ideas/issues/485

A previous plan called for the beginning of a JIT in 3.12, seen as "Trace optimized interpreter" here: https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....