
Don Stewart wrote:
wqeqweuqy:
T Willingham wrote:
On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander
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 Yea the optimization flags don't have any real effect on the FPS atm. The engine is bottlenecked by the OGL specific stuff.
The way it looks now i don't think theres going to be any performance problems - not that this is trying to be a bleeding edge 3d engine, but whatever. Tree data structures seem to adapt pretty well to being recreated each frame. I'm not sure how smart the GC is in regards to that though. Using matrices the same way performed really poorly. Replacing the matrix with a Region-QuadTrie caused a huge performance boost. IIRC the matrix stuff was using like 30% cpu according to the profile data and the Tree based approach used basicly 0% heh.