[Haskell] ANNOUNCE: OmegaGB, Haskell Game Boy Emulator

[Claus Reinke]

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