> 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.
Do the writes to the unboxed mutable bool vector also involve locking?
ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
81–90 of 120 posts
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#82> 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?
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#83> [Rust] 0.12 is so much prettier; vec[i] instead of vec.get(i), for instance That was just a momentary bit of weirdness, vec[i] has since returned. EDIT: Further down, the author acknowledges that this has been fixed. That's what I get for commenting before scrolling the whole way down!
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#84Obligatory question: what compiler options did you use for c++? Good first try is -o3 -march=native. It really makes huge difference in case of C/C++
It's in the makefile in that repo: g++ cpp.cpp -std=c++11 -Wall -O2 -march=native -o cpp I was originally using -O3 but then someone found that -O2 is actually faster in this case.
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#85Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#86Earlier quoted context omitted.
It is idiomatic in highly performance-sensitive Java code though. Hopefully it won't be necessary in Java 9 or 10 when unboxing support is brought in. I've added a note regarding the change, but I'm off to bed in a moment (AEST timezone). I'll separate the Java versions tomorrow.
You have a link to Java 9/10 class unboxing? I've been googling for it and can't find any information on it.
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#87C++ wins again. There's really no competition.
Meh. Only if you value performance above correctness and maintainability. Besides, C wasn't tested. C would win if it were, I'm pretty sure.
I don't understand why this myth persists, despite the fact that Fortran has been beating C at several benchmarks for as long as C has existed.
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#88I'd really like to see a "pull out all the stops" benchmark using highly-optimised Asm for the two architectures, as then it's just a matter of how much you can squeeze out of the CPU itself and not something limited by the thick layers of language abstractions on top of that. That would be a nice theoretical maximum to compare against. Edit: I tested the C++ version on my 5-year-old i7, with an even older compiler (…
Re: ARMv7 vs. x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more
#89Earlier quoted context omitted.
I'm pretty sure you can write correct and maintainable code in any language. Whether its users do is a different question.
If even top-notch teams like Mozilla cannot ship large C/C++ codebases without security holes, it seems legitimate to state that people cannot write correct code in that language.
* They've alienated many Firefox users thanks to many bad UI changes. They've continued to do this even after the users have strenuously objected to these unwanted changes. Firefox's share of the market has thus dropped from 35% to probably sub-10% these days.
* Many of the remaining Firefox users still point out that Firefox is slower and more bloated than other browsers. Although Mozilla often rejects or ignores these complaints, my years of software development experience have taught me that when many users say there's a problem, there very likely is one, even if we the developers can't reproduce it.
* Firefox for Android hasn't been picked up by many users.
* Firefox isn't an option on iOS. (Although I guess we can't fully blame Mozilla for this.)
* Firefox OS is floundering. The devices available so far have fared very poorly in reviews. Some of these reviews are among the harshest I've ever seen for any software or hardware product.
* Thunderbird is on life support.
* Rust is still pre-1.0, and will be like this for several more months, at the very least.
* Servo depends on Rust, so it being a viable option is still years away.
* There was that whole Eich debacle. It was pathetic, no matter how you look at it.
* Bugzilla is long forgotten these days.
* Despite absolutely massive funding from Google and now Yahoo, Mozilla hasn't managed to put out any other product that people actually want to use.
When I look at that track record, it's just one failure or disaster after another. It's not top-notch at all. So I'm not surprised that they have trouble using C and C++. They seem to be having severe trouble with pretty much everything they do!