[runevault]

Out of curiosity when did you write that interpreter? The entire dotnet ecosystem has seen massive speed improvements over the years, particularly for anyone who last tried them during the Framework era. Hell they even put work in to improving tail calls which the c# compiler doesn't even take advantage of (also either in the dotnet 9 or 10 timeframe f# added an attribute to make it so a recursive call that isn't a tail call throws a compiler error so you can't accidentally screw that up).

[z500]

It's .NET 10 lol. It's not so slow you can't write stuff for it, I have implementations of Conway's game of life, Huffman compression, and a minimal TUI. The main problem is doing almost anything in it involves a method lookup. And there are almost certainly places I could have done things more smartly.

One thing I do want to try out is publishing it with native AOT. I had a lot of luck with that on one of my other F# projects, I got like a 75% speedup out of it. I understand the JIT is supposed to outperform native AOT in the long term but I haven't seen it reach that speed.

[nckslv29]

Author here! I actually tried using AOT and it actually decreased the performance by about 35%. I think it's because Game Boy games tend use a small number of instructions a lot more than the others, so the JIT can optimize for them, while AOT has to be more conservative.

[z500]

That makes sense. The part where my program really benefits is in a bottleneck area that you always have to go through and where you visit every code path in it.

[runevault]

AOT vs JIT is always interesting since JIT depends on the runtime actually deciding to bother running the later passes to get more optimized code.

And sorry for the paranoia, I find a lot of people tried f# or even c# back in 4.x Framework era and think it hasn't changed.