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

111–120 of 120 posts

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

#111

Post by mrottenkolber »

wtf_is_up wrote: post #79
mrottenkolber wrote: post #45

Earlier quoted context omitted.

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?

Many others were able to send pull requests. What's you're issue?

The original code was badly written so that is was hard to understand the algorithm. I tried to rewrite it but it took longer than I had patience for.

The snarky tone comes from the fact that people often post "benchmarks" including languages they can't program in resulting in a misrepresentation.

E.g. Lisp jumped from the bottom to the center (as expected) of the benchmarks after somebody donated a sane implementation.

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

#113

Post by mrottenkolber »

jawngee wrote: post #52
mrottenkolber wrote: post #45

Earlier quoted context omitted.

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?

You should ask for a refund.

I should, he used SBCL ticks (relative unit of time) as if they were milliseconds.

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

#114

Post by Jakuv2000 »

TheLoneWolfling wrote: post #101
kibwen wrote: post #93

Earlier quoted context omitted.

I have no particular love for Mozilla (no more than any other corporation), but your points all seem facile. 1) Regardless of whether anyone thinks Firefox's UI changes have been for the better, it's not possible to alienate Firefox users via UI changes because Firefox still offers the most customizable UI of any browser you've heard of. What are users going to say? "Damn you Mozilla, you made your browser look just…

Regarding 1, although a single data point does not a trend make, I will say that I switched away from Firefox due to multiple UI changes and removing customization options. I switched to Pale Moon. In other words, personally, you are incorrect. FF no longer "still offers the most customizable UI of any browser you've heard of". (Simple enough: FF removed options that PM kept. Hence, FF is not more customizable than P…

I switched away from Firefox for the same reasons. Even if the UI was as customizable as is claimed, I don't want to waste my time recustimizing it every six weeks, or whenever a new Firefox release comes out.

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

#115

Post by igouy »

nkurz wrote: post #95

Not that the article does this, but since my current bandwagon is that assessing performance by comparing the source of two programs without consideration of the compiler and target processor is silly, I decided to try out the C++ version with several compilers and options. Renaming the file to 'lpath.cpp' and compiling with 'cc lpath.cpp -std=gnu++11 -Wall -Oxxx -march=native -o lpath-cc-Oxxx' here's what I found an…

>>The article is wonderfully specific about what was used…I'm missing something -- where does it say which version of JDK was used?

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

#116

Post by igouy »

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

Earlier quoted context omitted.

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.

When "the longest path problem" is reduced to indexed-access to an integer-sequence, does it become a duplicate of fannkuch?

http://benchmarksgame.alioth.debian.org/u64q/performance.php...

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

#117

Post by brucer »

logicchains wrote: post #109
brucer wrote: post #98

I'm really impressed you implemented this in so many languages! I was curious how fast Javascript would run this, so I ported the lua example over, it ran in 2200msec on my mac laptop. I'm not sure it's a great comparison benchmark however, because there are some obvious optimizations you can make. I added a simple cache to avoid recalculating travel costs for leaves and it now runs in 150msec. var fs = require('fs')…

Nice, your cached version is the fastest by far, although it uses a different algorithm. Running with `node js.js` without the cache, it takes around 6 seconds, close to Dart and Haskell.

I just realized I overthought the caching scheme, and removing one check made it 3x faster :)

  function getLongestPathCached(nodes, nodeid, visited, depth) {
    var idx;
    visited |= 1  max) {
          max = dist
        }
      }
    }
    visitCache[idx] = max;
    return max;
  }

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

#118

Post by logicchains »

brucer wrote: post #117
logicchains wrote: post #109

Earlier quoted context omitted.

Nice, your cached version is the fastest by far, although it uses a different algorithm. Running with `node js.js` without the cache, it takes around 6 seconds, close to Dart and Haskell.

I just realized I overthought the caching scheme, and removing one check made it 3x faster :) function getLongestPathCached(nodes, nodeid, visited, depth) { var idx; visited |= 1 max) { max = dist } } } visitCache[idx] = max; return max; }

Nice! That's almost as fast as the C++ one using caching; your algorithm must be better.

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

#119

Post by mrottenkolber »

lispm wrote: post #110
mrottenkolber wrote: post #34

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

I have improved it. https://github.com/logicchains/LPATHBench/blob/master/lisp.l...

Thank for the effort! Not sure how fleshed out the other implementations are but Lisp vs C now shows what I would have expected:

* SBCL can produce impressive x86 code

* It's ARM branch is pretty new, so it but 30% isn't too bad.

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

#120

Post by zackangelo »

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 was able to get the Scala version down to within ~100ms of the Java version while still using case classes.
Post reply on HN