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

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 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