[Haskell-cafe] Re: Memory efficiency questions for real-time graphics

[Neal Alexander]

Don Stewart wrote:
> wqeqweuqy:
>> T Willingham wrote:
>>
>>> On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander <wqeqweuqy at hotmail.com> 
>>> 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.