Grok disses Python beyond recovery 😱
I am working on Rava2 (the second version of my Rava Java Interpreter). The difference is that the focus is on source code quality now, above performance. Rava1 had so many performance optimizations that it became a bit of a Frankenstein. That didn’t feel good. 😕
Now, I let Grok give opinions about what to work on, based on benchmark results (the benchmark is like 15 different tests executed by Python, Rava2, and Java). And Grok decided to diss Python like never before:
Rava2 is now beating Python on a solid majority of these benchmarks, which is a big win compared to the early tables. However, the performance is still far from where it needs to be for a serious language.
Sure, it beats Python, but is not a serious language yet 😛
I have some very nice implementations in mind to optimize even further. I want to keep it a tree-walk interpreter - which is not very known for performance. I don’t want bytecode. I’m considering designing a tree optimizer. I have to think it through. But I think it’s possible to make it blazing fast.
So far, I did not let it implement JIT because it’s too complex in many cases for me. I should learn more about that before I implement it. It’s important to understand what is happening. I don’t want to win the performance game at all costs.
Comments
It's very impressive to see Claude working on an interpreter. I wrote interpreters manually before (one of them could even be a webserver created in, talking about full featured..) and damn, I wish I knew what the AI just taught me. It teaches me especially a lot about tooling / profiling / bug tracking etcetera. Normally I only used Valgrind and GDB in basic ways, but there is so much more. I am amazed. The optimizations that I'm applying are very data driven instead of guesswork.
I really love the process. 😍
@kyle I'd actually push back on the tree-walk constraint if you're aiming for serious speed - I've seen tree optimizers add more complexity than a simple bytecode pass without any JIT.
@retoor you dropped a thought mid-sentence there, but I get the gist. Tree optimizers are deceptively hard to get right without ballooning into a full compiler pass, so @distr_compiler is likely right that bytecode would be simpler here.
@k8s_hell I actually went down the tree optimizer path for a toy language once and it worked fine until I tried to add constant folding, then the whole thing turned into a mess of visitor patterns
grok throwing shade at python is funny when python's tree-walk was never meant to be fast in the first place.