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

[Don Stewart]

t.r.willingham:
>    As my first Haskell exposure, I've been working through Real World
>    Haskell.
> 
>    I am considering converting some of my C++ graphics libraries to
>    Haskell.  I've done a fair amount of googling on the subject, however
>    I haven't quite been able to find clear answers to some of following
>    issues.
> 
>    (1) Using an OpenGL vertex array (a contiguous chunk of memory which
>    is handed to the graphics card) is important.  I see the source code
>    of Frag does this, so it looks like we're good.  Check.
> 
>    (2) In-place modification of the vertex array is important.  Every
>    vertex changes on each frame update.  And we always want more
>    vertices.

I imagine these are mutable arrays, so that's fine.
  
>    (3) Growing and shrinking the vertex array efficiently is important.
>    Here the behavior of C++ std::vector happens to be ideal.  When
>    growing, extend the array in-place if possible (using reserved space
>    if any), otherwise allocate a new chunk ("amortized constant time").
>    When shrinking, do nothing but record the smaller size; the unused
>    memory chunk is reserved for possible future growth.

Easy enough. You're working with raw arrays of memory , I assume (e.g.
UArrays or Ptr a?)
  
>    (4) Doing little to no allocations each frame update is important.  In
>    the current C++ version, zero allocations occur during a normal frame
>    update.  When the vertex array changes, that is the only allocation
>    which happens.

This is certainly possible. To confirm it, look at the generated Core
code, produced by GHC (with the ghc-core tool).

See the realworldhaskell chapter on optimisation.
  
>    To give a context for all of this, I am applying a non-linear
>    transformation to an object on every frame.  (Note: non-linear, so a
>    matrix transform will not suffice.)
> 
>    The object is described by a certain function, and is generated from a
>    3D domain grid.  The user can change the resolution of the grid on the
>    fly, while the object is moving.  (Hence the need for grow/shrink
>    efficiency.)
> 
>    Given that (1) is out of the way, what's the best I expect from
>    Haskell concerning (2)-(4)?

Seems fine. You'll be working at a low level, with strict, mutable,
unboxed data structures, but that's fine: the machine loves them.

-- Don