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

41–50 of 120 posts

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

#41

Post by logicchains »

bad_login wrote: post #33
jarcane wrote: post #7

The Racket and Lisp comments are a bit odd. To the best of my knowledge Typed Racket does support gradual typing, and as well, comparing it's compatibility to Scheme is a category error: Racket is not Scheme anymore, that's why it's called Racket now and not PLT Scheme.

I just made the code a little more idiomatic - avoided using the box arount max - used a named let for loop and made it terminal recursive removed the box improve performance from 10s to a 9s. #lang typed/racket (struct: route ([dest : Integer] [cost : Integer]) #:transparent) (struct: node ([neighbours : (Listof route)]) #:transparent) (: str->int (String -> Integer)) (define (str->int str) (define n (string->number…

Thanks! I updated the code.

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

#42

Post by logicchains »

IsTom wrote: 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?

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

#43

Post by logicchains »

kyrra wrote: post #40

In the Go code, if you want to ignore an err you can write _ in its place. Another things that I'm not sure you can even do anymore is disable bounds checking by adding "-gcflags -B" to the compile.

> In the Go code, if you want to ignore an err you can write _ in its place.

Not a good habit to get into though.

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

#44

Post by 0xFFC »

logicchains wrote: post #38
nly wrote: post #32

Seeing as how they're likely the most widely distributed Java runtimes on ARM, I would have liked to see Dalvik and ART benchmarks for the Java code Key takeaway for me is that statically typed languages that are compiled to native code are still 2-3x faster than the fastest JITs. On both platforms.

Interestingly, now that someone submitted a change to the Java implementation, such that it doesn't use classes (unboxing is simulated by using arrays for the data instead), it runs much closer to native speed.

can you explain a little further ?

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

#45

Post by mrottenkolber »

mrottenkolber wrote: post #34

That is some horrible Common Lisp code. I have to try this out....

Nope sorry. I tried to fix this up a little but this is too convoluted for me to work with.

Q1: Why do you need an adjustable array?

Q2: Why do you need a structure with a single slot (node)?

If you want to benchmark a piece of code, please write a nice version and then optimize it. How can I reason about a benchmark result if the code is not understandable?

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

#46

Post by super_tycoon »

threeseed wrote: post #39
logicchains wrote: post #24

Earlier quoted context omitted.

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 no…

Managed to get a 22% improvement on Core i7 OSX / Oracle JDK8 by replacing the for iterator-style loop with a C style one. Am I missing something because this shouldn't be faster. ArrayList neighbours = nodes.get(nodeID).neighbours; for(int i=0;i Also add -Xbatch as a parameter which gives another few percentage points.

I refactored it to be more static and final/const. Also used an int[][] for the node data.

Original comment is on proggit. Went from 1600ms to 900ms.

http://pastebin.com/w2BC8fNg

http://www.reddit.com/r/programming/comments/2pvf68/armv7_vs...

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

#47

Post by bsaul »

logicchains wrote: post #24
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 no…

I don't think this improvement is really fair though. Everybody heard the same thing as you did : arraylist are ok performance wise. The optimisation of using arrays and static global variables and remove use of any object isn't something that leads to readable code in the long run, nor is it the code your regularely see in everyday software.

You should include both your old java code with the new one. Call your version "enterprise java" and the other "optimized java". If anything, that could be useful to people coding in java and having performance issue ( otherwise they'll have to look for it in git history, which they'd have no reason to).

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

#48

Post by kev009 »

logicchains wrote: post #37
kev009 wrote: post #35

I'm not really sure what this data means because amd64 and ARMv7 are ISAs. For instance, you could make a very deep and superscalar ARMv7 chip that blows a typical amd64 out of the water if you sacrifice size and power. Is the intent simply to show that some language backends are not optimized? Otherwise, without something like "These two chips and clock-for-clock or watt-for-watt it looks like this" it seems meaning…

It's not meant to compare AMD64 and ARMv7 architectures, it's meant to compare the performance of various language compilers/runtimes on two common AMD64 and ARMv7 chips.

Not sure why the downvote as that was my request for clarification.

Point being, if you want to benchmark language backends, it doesn't make a lot of sense to cross chips without making mulch-dimensional benchmark (i.e adding in clock or power vectors).

After rereading closely, the intent of the article is saying "50% slowdown for backend X on x86, 70% slowdown for backend X on ARM." The subtle difference is that you are keeping comparisons of slowdown in the family and only making analogy to the other arch by slowdown percentage.

It's still susceptible to ISA implementation (for instance an in order Atom might fare a lot worse for typical backends), but mildly interesting.

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

#49

Post by logicchains »

0xFFC wrote: post #44
logicchains wrote: post #38

Earlier quoted context omitted.

Interestingly, now that someone submitted a change to the Java implementation, such that it doesn't use classes (unboxing is simulated by using arrays for the data instead), it runs much closer to native speed.

can you explain a little further ?

I think it's easier to read the code:

https://github.com/logicchains/LPATHBench/blob/master/jv.jav...

Instead of a vector of node classes, there's a

    static final int[][] nodes;
Which is used in a similar manner to a vector of node classes, but due to containing primitives (ints) is unboxed.

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

#50

Post by logicchains »

bsaul wrote: post #47
logicchains wrote: post #24

Earlier quoted context omitted.

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 no…

I don't think this improvement is really fair though. Everybody heard the same thing as you did : arraylist are ok performance wise. The optimisation of using arrays and static global variables and remove use of any object isn't something that leads to readable code in the long run, nor is it the code your regularely see in everyday software. You should include both your old java code with the new one. Call your vers…

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.

Post reply on HN