[Haskell-cafe] Memory efficiency questions for real-time graphics
dons at galois.com
Mon Oct 27 22:07:14 EDT 2008
> As my first Haskell exposure, I've been working through Real World
> 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
> (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
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
> 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.
More information about the Haskell-Cafe