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