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

51–60 of 120 posts

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

#51

Post by lispm »

logicchains wrote: post #31
lispm wrote: 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.

here is a much faster version:

https://gist.github.com/lispm/6066e1eeadf943910c47

You might want to adapt it...

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

#52

Post by jawngee »

mrottenkolber wrote: post #45
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?

You should ask for a refund.

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

#53

Post by logicchains »

lispm wrote: post #51
logicchains wrote: post #31

Earlier quoted context omitted.

Nice, re-running the benchmark with the new code now. *Edit: and, it's done.

here is a much faster version: https://gist.github.com/lispm/6066e1eeadf943910c47 You might want to adapt it...

I'm off to bed now, I'll pull it in the morning.

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

#54

Post by imanaccount247 »

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…

>However, my experience has shown that Sun/Oracle JVM usually out performs OpenJDK. Even in development

Your experience seems to be filtered through your misconceptions. It is the same code base.

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

#55

Post by kuschku »

logicchains wrote: post #10
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.

>To the best of my knowledge Typed Racket does support gradual typing If you take a Racket program and change the language to Typed Racket, you'll get flooded with compiler errors. Or at least that's been my experience. >Racket is not Scheme anymore I'll update the post to note this, thanks.

You can use typed/racket with optional types, it’s kinda easy.

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

#57

Post by pja »

Based on profiling the C++, this seems to be more a benchmark of function call cost in various languages than anything else - this code makes 42975348 calls to

  int getLongestPath(std::vector > const&, int, std::bitset)
Which is fine, but seems a slightly limited platform / language comparison!

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

#58

Post by klibertp »

logicchains wrote: post #10
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.

>To the best of my knowledge Typed Racket does support gradual typing If you take a Racket program and change the language to Typed Racket, you'll get flooded with compiler errors. Or at least that's been my experience. >Racket is not Scheme anymore I'll update the post to note this, thanks.

> If you take a Racket program and change the language to Typed Racket, you'll get flooded with compiler errors. Or at least that's been my experience.

That's because when using `#lang typed/racket` you literally change the language you're writing and that includes the syntax of some very fundamental forms (like define or struct).

You can mix typed and untyped code freely as long as they are separated by module boundaries. Something like this:

    #lang racket/base

    (module with-types typed/racket
      (provide a)
      (: a (-> String Integer))
      (define (a x) 0))

    (module without-types racket
      (require (submod ".." with-types))
      (provide a))
But it's definitely not as convenient as Erlang's Dialyzer, TypeScript, Dylan or similar success/gradual/occurrence/soft-typing solutions for sure.

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

#60

Post by klibertp »

kuschku wrote: post #55
logicchains wrote: post #10

Earlier quoted context omitted.

>To the best of my knowledge Typed Racket does support gradual typing If you take a Racket program and change the language to Typed Racket, you'll get flooded with compiler errors. Or at least that's been my experience. >Racket is not Scheme anymore I'll update the post to note this, thanks.

You can use typed/racket with optional types, it’s kinda easy.

How? The docs say (http://docs.racket-lang.org/ts-guide/more.html#(part._when-a...) that you have to provide type annotations in certain cases.
Post reply on HN