3 ms·
> Functional code in Haskell/OCaml can be faster than imperative code using iorefs. IORefs involve locking. They are bad performance-wise. An algorithm like th
by IsTom 12y ago
> Functional code in Haskell/OCaml can be faster than imperative code using iorefs.
IORefs involve locking. They are bad performance-wise. An algorithm like this should be done either fully functionaly without any mutation at all or in ST.
- logicchains 12y agoDo the writes to the unboxed mutable bool vector also involve locking?
- IsTom 12y agoI would assume that no, but AFAIK GHC has separate (badly optimized) path for garbage collection on mutable data.
- eschew 12y agoGHC, at least, uses the same implementation for IORef and STRef: http://hackage.haskell.org/package/base-4.3.1.0/docs/src/GHC-IORef.html#IORef http://hackage.haskell.org/package/base-4.3.1.0/docs/src/GHC... Poking through GHC's runtime source, I see a writer barrier but no locking -- did I miss something?
- IsTom 12y agoLooking deeper you're right, it seems to use atomic CAS operations. Still mutable data is bad for GC and optimization pass (can't share expressions etc.)