Live data from Hacker News

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

github.com

31–40 of 120 posts

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

#31
post #27

(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 (th…

Nice, re-running the benchmark with the new code now.

*Edit: and, it's done.

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

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

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

#33
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 str))
    (if n (numerator (inexact->exact (real-part n))) 0))

  (: read-places (-> (Vectorof node)))
  (define (read-places)
    (define lines
      (file->lines "agraph"))
    (define num-lines (str->int (car lines)))
    (define nodes (build-vector num-lines (lambda (n) (node `()))))
    (let loop ([i : Integer 0])
      (define nums (string-split (list-ref (cdr lines) i)))
      (define len (length nums))
      (when (and (> len 2) (> (length lines) (+ i 2)))
          (let ([node-id (str->int (list-ref nums 0))]
                [neighbour (str->int (list-ref nums 1))]
                [cost (str->int (list-ref nums 2))])
            (define new-node (node
                              (append (node-neighbours (vector-ref nodes node-id))
                                      (list (route neighbour cost)))))
            (vector-set! nodes node-id new-node)
            (loop (+ i 1)))))
    nodes)

  (: get-longest-path ((Vectorof node) Integer (Vectorof Boolean) -> Integer))
  (define (get-longest-path nodes node-id visited)
    (vector-set! visited node-id #t)
    (define sum
      (foldr
       (lambda ([neighbour : route] [max : Integer])
         (if (not (vector-ref visited (route-dest neighbour)))
             (let ([dist (+ (route-cost neighbour) (get-longest-path nodes (route-dest neighbour) visited))])
               (if (> dist max)
                   dist
                   max))
             max))
       0
       (node-neighbours (vector-ref nodes node-id))))
    (vector-set! visited node-id #f)
    sum)

  (define nodes (read-places))
  (define visited : (Vectorof Boolean) (build-vector (vector-length nodes) (lambda (n) #f)))
  (define start (current-inexact-milliseconds))
  (define len (get-longest-path nodes 0 visited))
  (define duration (- (current-inexact-milliseconds) start))
  (printf "~a LANGUAGE Racket ~a\n" len (inexact->exact (floor duration)))

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

#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 meaningless.

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

#36
This is a comparison of specific implementations of the two processor architectures. The benchmarking is still an interesting work, but it isn't a straight comparison of language performance across architectures. It might be a more enlightening result to know the number of opcodes each run executed.

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

#37
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.

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

#38
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.

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

#39
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…

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.
Post reply on HN