Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



GHC, at least, uses the same implementation for IORef and STRef: 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?


Looking 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.)


Do the writes to the unboxed mutable bool vector also involve locking?


I would assume that no, but AFAIK GHC has separate (badly optimized) path for garbage collection on mutable data.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: