i've seen no replies to this so far, so just a few brief comments: first, many readers like myself may have skipped this announcement because they aren't currently interested in the specific application. what the announcement didn't say is that there is a small development blog for the project, browsing which might be of interest to haskell hackers and implementers alike. we get so few experience reports, and this project includes modeling a code- interpreting virtual machine with a gui, and providing a gui to the model itself, so it might appeal to non-gamers as well (and it is always nice to hear about haskell being applied to fun projects;-): http://www.mutantlemon.com/omegagb/devlog/ second, calling for help with optimisation is okay, but i doubt that many readers will download a full application to search for possible problems in it (there is always the chance of one of the profiling/debugging projects looking for examples like this, but i don't know whether there are any such projects active right now). you did provide a useful overview of your approach, your problems, and the techniques you've tried so far to resolve them, but that kind of overview might be too abstract to provide concrete tips with any certainty about their usefulness. for example, looking at your overall representation of machine instructions and machine state suggests possible problems with space leaks. the tuples are non-strict, so the updates caused by instructions could possibly accumulate until another instruction needs to inspect the results of those updates.

updateMachineDisplayFrame :: JoypadKeyStates -> ((RegisterStates, Memory), IrqStates) -> (Display, ((RegisterStates, Memory), IrqStates))

but if you actually display a representation of the machine state at each step, that alone should force all pending instructions, so perhaps this isn't an issue in the real program. then again, your experience with unboxed arrays suggests that perhaps this is an issue after all. and even if there are no runaway space leaks, repeatedly delaying operations only to have them forced a few moments later might have a negative impact on performance.

I originally started this project to explore whether haskell is really a capable language in the domain of performance critical applications. I think that with the right optimizations, OmegaGB will be able to do real time emulation. Unfortunately, I am not experienced enough to know what kind of optimizations to use. This is why I am calling out for help.

skimming through your blog, two things come to mind: - the virtual machine for such a device is unlikely to do any operation unless the results are needed, so you probably want your state representations to be strict in all components. depending on how well the strictness analyser fares with your code, that might save some intermediate thunk building - instead of interpreting the machine instructions in executeInstruction, you could implement them directly in your execution monad, eliminating one level of interpretation at each step (ie, there'd be a push :: srtype -> ExecutionAST ()); if you can also switch from lists of instructions to monadic sequences of instructions, there might be further gains from asking ghc to inline the instructions skipping explicit representations, as per the second suggestions, might make extracting debug information slightly more difficult, so you may want to keep the explicit version around, or integrate debugging into your execution monad (just something to keep in mind). oh, lest i forget, there's also: http://www.haskell.org/haskellwiki/Performance just to get some discussion going;-) claus