ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more

Re:ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Ni... by IsTom on Saturday December 20, 2014 @08:05AM (#8776540)

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

[ Parent | on HN ]

Re:ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Ni... by eschew on Saturday December 20, 2014 @11:04AM (#8776927)

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?

[ Parent | on HN ]

Re:ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Ni... by IsTom on Saturday December 20, 2014 @02:09PM (#8777563)

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

[ Parent | on HN ]

Re:ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Ni... by logicchains on Saturday December 20, 2014 @09:03AM (#8776641)

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

[ Parent | on HN ]

Re:ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Ni... by IsTom on Saturday December 20, 2014 @02:01PM (#8777534)

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

[ Parent | on HN ]