[Haskell-cafe] ST Vector / STRef -- Performances and allocation

[Bertram Felgenhauer]

Guillaume Bouchard wrote:
> Thank you ! I'm now in an equal time with the C code ;)
> 
> On Sun, Jun 19, 2016 at 3:12 PM, Bertram Felgenhauer via Haskell-Cafe
> <haskell-cafe at haskell.org> wrote:
> > Guillaume Bouchard wrote:
> >> - PRef (Unboxed bytearray of size 1, the closest thing to an unboxed
> >> stack allocation) : 86ms
> >> - URef (Unboxed vector of size 1) : 130ms
> >> - SRef (Storable vector of size 1) : 43ms (This is an improvement !)
> >> - BRef (Boxed ref) : 137ms
> >> - STRef : 54ms (this was my baseline)
> >
> > You really shouldn't use any mutable variable at all for this, but pass
> > the values around as function arguments instead:
> 
> Nice ! This is so obvious that I did not thought about it. Thank you.
> (Thank you for the followup-mail, it is clear that it may be easier
> for GHC to unbox / put in register "normal variable" than more complex
> type such as the one involved in PRef).

I'd say that the complexity of the type isn't the main obstacle here,
but mutability. The point is that when a value is unboxed, one
essentially creates a copy of it (on the stack, and possibly on the heap
if one ends up re-boxing the value later on). For ordinary Haskell values
that is not a problem; they are immutable and a copy is identical, for
all purposes, to the original. The only potential downside to unboxing
is that some memory may be wasted. With mutable data, however, copies
cannot track updates to the original, so unboxing is no longer safe
unconditionally. It still could be done if the mutable structure is
never shared, but it requires a precise non-sharing analysis. I suspect
that this kind of analysis does not (yet?) exist in ghc, because it
would not benefit pure code.

Cheers,

Bertram