Live data from Hacker News

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

github.com

81–90 of 120 posts

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

#81
post #25

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

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

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

#82
post #66
post #25

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

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!

I wish there was more substance to the Rust section. Most of it is in strike-out and the remaining text has more to say about how you would do things in OCaml than Rust.

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

#84

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

When visited was changed from a vector to a bitset, why is it not passed by reference anymore?

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

#86

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

Have you googled something like value classes?

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

#87
post #59
post #56

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

Why do people still assume C is always fastest? You can write C++ and D like it's C and it'll produce identical machine code. Which means that after profiling an idiomatic C++/D program(and assuming for the sake of argument that C is faster, which isn't even close to necessarily true) you could rewrite the hotspots in C-style and achieve the same performance.

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

#88

I'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 (…

You have to give Intel/AMD a lot of credit for improving the performance of existing binaries. They've reduced CPI and improved ILP a lot in 16 years, not to mention vastly improved various forms of prediction, caching and speculation. A lot of the performance improvement gleaned from modern compilers will be better reduction of the C++ language itself, e.g. smarter inlining, LTO, devirtualisation etc.

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

#89

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

Is Mozilla really a "top-notch team", though? When I look at their track record, it's not what I'd expect from a top-notch team:

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

Post reply on HN