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

71–80 of 120 posts

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

#71

Post by alain94040 »

Symmetry wrote: post #70

So if it's a "Galaxy S3 with 2GB of ram and a quad-core 1.3ghz processor" then this should be the version with the Exynos SOC. That means that these are cores inside are A9s. The Intel cores are from the Westmere generation. I wonder how much of the difference we're seeing between various languages is the quality of the code their compilers generate for various backends and how much is due to the different languages…

Correct. Not to mention that benchmarking on a mobile phone is tricky. You need to make sure your CPU won't throttle due to heat. Your average mobile CPU can't run at 100% for very long. The more benchmarks you run back to back, the slower you get, so your measurements can easily be completely wrong.

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

#73

Post by MichaelGG »

userbinator wrote: post #62
cbd1984 wrote: post #59

Earlier quoted context omitted.

Meh. Only if you value performance above correctness and maintainability. Besides, C wasn't tested. C would win if it were, I'm pretty sure.

I'm pretty sure you can write correct and maintainable code in any language. Whether its users do is a different question.

If even top-notch teams like Mozilla cannot ship large C/C++ codebases without security holes, it seems legitimate to state that people cannot write correct code in that language.

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

#75

Post by [deleted] »

MichaelGG wrote: post #73
userbinator wrote: post #62

Earlier quoted context omitted.

I'm pretty sure you can write correct and maintainable code in any language. Whether its users do is a different question.

If even top-notch teams like Mozilla cannot ship large C/C++ codebases without security holes, it seems legitimate to state that people cannot write correct code in that language.

[deleted]

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

#76

Post by acqq »

alain94040 wrote: post #71
Symmetry wrote: post #70

So if it's a "Galaxy S3 with 2GB of ram and a quad-core 1.3ghz processor" then this should be the version with the Exynos SOC. That means that these are cores inside are A9s. The Intel cores are from the Westmere generation. I wonder how much of the difference we're seeing between various languages is the quality of the code their compilers generate for various backends and how much is due to the different languages…

Correct. Not to mention that benchmarking on a mobile phone is tricky. You need to make sure your CPU won't throttle due to heat. Your average mobile CPU can't run at 100% for very long. The more benchmarks you run back to back, the slower you get, so your measurements can easily be completely wrong.

Exactly, the speed of mobiles is limited to short bursts to preserve the battery. And sometimes even the worse code gets more CPU if it hits the right patterns.

The timings presented are also confusingly presented for my taste.

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

#77

Post by [deleted] »

logicchains wrote: post #8
atoponce wrote: post #5

The LuaJIT results don't surprise me. I've always been impressed with LuaJIT. The OpenJDK results also don't surprise me. If you work in a Java shop, you learn very quickly to throw out OpenJDK in favor of Sun/Oracle Java. OpenJDK is indeed a "steaming pile of crap". However, I would have liked to see Julia and Javascript benchmarks in those results. I've heard great things about Julia, and knowing just how incredibl…

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

[deleted]

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

#78

Post by wtf_is_up »

icefox wrote: post #74

Something not measure that is just as important as speed (if not more so) was how long it took to create a working program in each language.

Agreed. We must also consider what a pain in the ass it was to set up the toolchains and/or runtimes for several of the tested languages.

I'm willing to trade a little performance and do a little extra error checking if it means I can just do:

    GOARCH=arm go build
and then copy the binary over.

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

#79

Post by wtf_is_up »

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?

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

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

#80

Post by profquail »

melling wrote: post #72

"The F# was however nowhere near as fast as the OCaml" I find this a bit odd. Microsoft should be able to build a better compiler. I thought F# was getting a lot of traction.

F# is quite fast (I've written a good deal of F# code) and it has seen a big uptick in adoption over the last couple of years.

I had a look at the F# code and it's not all that efficient (there are a number of intermediate data structures being created that don't need to be). I'll have a go at optimizing the code to see if I can improve the performance.

Post reply on HN