wqeqweuqy: > T Willingham wrote: > > >On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander <[EMAIL PROTECTED]> > >wrote: > >>Even when generating one or more copies of "world" per frame the > >>performance > >>stays fine and allocations are minimal. > > > >Who says? That may be your particular experience from your particular > >tests. In my case, any copy of the "world" on each frame would have a > >catastrophic effect on the framerate, for any such definition of > >"world". > > > > Yea, this is just from my recent experience messing with a game engine > in Haskell - I'm only a few months into it though. > > So far, the GC hasn't been anywhere close to having a problem keeping up > with the monitors refresh rate. Even with several world states being > folded into a frame. > > The memory usage is pretty flat too, at least with GLFW (the GLUT > bindings had some issues there iirc). > > The test is pulling a pretty constant 1500 fps on this machine with the > background + 1 character running around and resources being streamed in > lazily. Not that that means much, but at the very least a GC run isn't > noticeable on the current data set. > > > Initially i expected this setup to perform badly, but i tried it anyway > out of curiosity. We'll see how it goes with full sets of data later i > guess heh. >
And, just to double check, you're compiling with a modern GHC, using say, -O2 -fvia-C -optc-O2 -funbox-strict-fields ? -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
