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

101–110 of 120 posts

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

#101

Post by TheLoneWolfling »

kibwen wrote: post #93
ShawnyShawny wrote: post #89

Earlier quoted context omitted.

Is Mozilla really a "top-notch team", though? When I look at their track record, it's not what I'd expect from a top-notch team: * They've alienated many Firefox users thanks to many bad UI changes. They've continued to do this even after the users have strenuously objected to these unwanted changes. Firefox's share of the market has thus dropped from 35% to probably sub-10% these days. * Many of the remaining Firefo…

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

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

#102

Post by dbaupp »

ShawnyShawny wrote: post #89
MichaelGG wrote: post #73

Earlier quoted context omitted.

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.

Is Mozilla really a "top-notch team", though? When I look at their track record, it's not what I'd expect from a top-notch team: * They've alienated many Firefox users thanks to many bad UI changes. They've continued to do this even after the users have strenuously objected to these unwanted changes. Firefox's share of the market has thus dropped from 35% to probably sub-10% these days. * Many of the remaining Firefo…

Almost all of those are just front-end/"marketing" and are orthogonal to the quality of the core C++ code itself (e.g. the JS engine, or the audio decoders).

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

#103

Post by rdc12 »

ShawnyShawny wrote: post #89
MichaelGG wrote: post #73

Earlier quoted context omitted.

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.

Is Mozilla really a "top-notch team", though? When I look at their track record, it's not what I'd expect from a top-notch team: * They've alienated many Firefox users thanks to many bad UI changes. They've continued to do this even after the users have strenuously objected to these unwanted changes. Firefox's share of the market has thus dropped from 35% to probably sub-10% these days. * Many of the remaining Firefo…

How many of your points actually deal with their ability to write fast/safe C++? Most of them deal with more management or UI design and their desire to write in Rust instead.

And considering where firefox was five years they have done a remarkable job at trimming it down, in particular in memory usage.

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

#104

Post by igouy »

logicchains wrote: post #14
th0br0 wrote: post #9

Earlier quoted context omitted.

It seems to me though, that the Java numbers aren't representative. As far as I know, JVM benchmarks should allow HotSpot etc to optimise the functions by calling them ~1k times before the actual benchmark happens. That doesn't seem to be the case in the code.

The same function is being called over and over millions of times, so hopefully that should give HotSpot a chance to kick in. I didn't want to add artificial warm up as I don't think that's representative of real code.

Check times with JMH

http://openjdk.java.net/projects/code-tools/jmh/

Also -XX:-PrintCompilation -XX:-PrintGC

https://wikis.oracle.com/display/HotSpotInternals/MicroBench...

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

#105

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…

tl;dr

Measurement is highly specific -- the time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads.

Same toy program, same computer, same workload -- but much slower.

Measurement is not prophesy.

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

#107

Post by logicchains »

wtf_is_up wrote: post #78
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.

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

The Arch Linux package repository proved really awesome here: for the vast majority of things (everything on x86) I could just `pacman -S myLang`. The hardest to install was SBCL on ARM, as I needed another Common Lisp to compile it, so had to get ClozureCL and use that.

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

#108

Post by logicchains »

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.

>I find this a bit odd. Microsoft should be able to build a better compiler.

It was running on Mono, not the Microsoft CLR.

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

#109

Post by logicchains »

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