Before GHC 9.8, optimizations were considered too unstable to be used with the bytecode interpreter. This restriction has been lifted, but is still regarded as experimental and guarded by -funoptimized-core-for-interpreter, which is enabled by default.
Does experimental mean “don’t depend on it because it might go away” or does it mean “if you depend on it, it might break suddenly but in the long run we intend to keep it”?
You can use it! We hope to drop the flag in the future, making —interactive -O2 just work if you specify it.
It’s worth keeping in mind that —interactive typically benefits from fast compile times more so than fast runtime, so -O is perhaps not what you want.
That said, with -O -fno-unoptimized-core-for-interpreter
you can tweak the trade off a bit
The flag is there to protect users from accidentally using optimizations with the interpreter because, historically, the bytecode compiler had bugs/was incomplete for optimized Core. Namely, it would produce invalid bytecode resulting in segfaults. But we’ve fixed a lot of these bugs in recent years. It’s a better time to use optimized core in the interpreter (if you want that trade off) than ever. If you run into any, let us know.
I would launch my sdl2 games from ghci and do a couple of things
Have a pipe where I could pass arbitrary actions in my engine’s effect system and get responses. This can be used to both query gamestate and modify it. Dev console for free (and it’s haskell!)
Hot reloading. Stash a pipe in foreign store and the game loop checks it every frame. If it finds a new game loop..use that instead.
So having the game run optimized and the (2) reloaded loops be optimized would be nice.
I already ran into a perf issue. The heap from ghci loaded stuff itself hurt pause times. -xn bandages over that.
