Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 120 posts

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

#21

Post by lazyjones »

jensnockert wrote: post #6
rwmj wrote: post #2

Which version of OCaml? The ARMv7 backend was rewritten about 2 years ago, and merged in 4.00. http://caml.inria.fr/mantis/view.php?id=5433 The new backend is supposed to be considerably faster on floating point code. This code looks integer only, and I don't have relative performance of old/new backend for integer code. As a wider question: Who cares much about ARMv7? ARMv8 is a completely different beast, requiring…

Except it's really hard to benchmark on ARMv8 since non-Apple hardware is expensive.

> hard to benchmark on ARMv8 since non-Apple hardware is expensive.

If Android will do - Cortex-A53 smartphones like the Huawei Ascend Y550 cost 120€ nowdays in Europe (about 4x the price of a Raspberry Pi).

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

#22

Post by logicchains »

bluecalm wrote: post #19

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.

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

#23

Post by steveklabnik »

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

#24

Post by logicchains »

mda wrote: post #20

That's some alien Java code indeed.

Any improvements you can see? The 'inner loop' of the code is:

    int getLongestPath(ArrayList nodes, int nodeID, boolean[] visited){
	visited[nodeID] = true;
	int dist, max=0;
	for(route neighbour: nodes.get(nodeID).neighbours){
	    if (!visited[neighbour.dest]){
		dist = neighbour.cost + getLongestPath(nodes, neighbour.dest, visited);
		if (dist > max){
		    max = dist;
		}
	    }    
	}
	visited[nodeID] = false;
	return max;
    }
The ArrayList of nodes could be changed to an array, but I don't imagine that'd be much faster (I've always heard that ArrayLists are just as fast as arrays, except for primitives).

*Edit: someone found a massive improvement, by replacing the node class with arrays, to simulate unboxing.

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

#26

Post by gaius »

logicchains wrote: post #18
gaius wrote: post #3

This is some quality work. The Java results are particularly striking! It would be interesting to see some more languages that have more than one implementation compared. What is the difference between FSharp and F#?

FSharp instead of F# is just a way of getting around issues with using the # character in the shell scripts that run the benchmark.

But he says F#, Haskell, Rust and Dart send their apologies. F# didn't have an Arch Linux package for ARM, and when I built it myself the compiler and runtime segfaulted upon use

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

#27

Post by lispm » 

    (defun get-longest-path (nodes node-id visited)
      (declare (optimize (speed 3) (space 0) (debug 0) (safety 0)
                         (compilation-speed 0)
                         #+lispworks (fixnum-safety 0))
               (type fixnum node-id)
               (type (vector node) nodes)
               (type (vector atom) visited))
      (setf (aref visited node-id) t)
      (Let ((max (loop for neighbour of-type route across (node-neighbours (aref nodes node-id))
                       unless (aref visited (route-dest neighbour))
                       maximize (the fixnum
                                     (+ (the fixnum (route-cost neighbour))
                                        (the fixnum (get-longest-path nodes (route-dest neighbour) visited)))))))
        (declare (fixnum max))
        (setf (aref visited node-id) nil)
        max))
Above Common Lisp version improves the runtime from 8.5 to 3.6 seconds in SBCL and from 30 seconds to 2 seconds in LispWorks 64bit. Computer: i7 Mac mini.

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

#29

Post by logicchains »

gaius wrote: post #26
logicchains wrote: post #18

Earlier quoted context omitted.

FSharp instead of F# is just a way of getting around issues with using the # character in the shell scripts that run the benchmark.

But he says F#, Haskell, Rust and Dart send their apologies. F# didn't have an Arch Linux package for ARM, and when I built it myself the compiler and runtime segfaulted upon use

Wow, you're right, no idea where that FSharp entry on the ARM results is coming from.

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

#30

Post by threeseed »

atoponce wrote: post #15
logicchains wrote: post #8

Earlier quoted context omitted.

>OpenJDK is indeed a "steaming pile of crap" Just to clarify, it performed as well as the Oracle JVM on x86. Its poor performance on ARM is just due to its lack of JIT compilation. >However, I would have liked to see Julia and Javascript benchmarks in those results. I'm happy to include Javascript or Julia implementations if someone supplies them. I wasn't comfortable with Julia enough to write one myself.

>> OpenJDK is indeed a "steaming pile of crap" > Just to clarify, it performed as well as the Oracle JVM on x86. Its poor performance on ARM is just due to its lack of JIT compilation. Understood. Admittedly, I'm a system administrator first, developer second. However, my experience has shown that Sun/Oracle JVM usually out performs OpenJDK. Even in development, on the Java teams I've had to support, OpenJDK is never…

> OpenJDK is never preferred or wanted

I would argue it's actually risky.

Almost every Java developer uses the Oracle version because (a) it is what is recommended for OSX which is a popular development platform and (b) the bundled tooling is much better than OpenJDK. Hence you shouldn't mix/match JVMs just in case you hit implementation differences.

Post reply on HN