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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
