Hacker News Reader

Comment by marblestation | Hacker News Reader

We do not claim that Rust is so much performant than C, we just showed that Rust can be as fast as Fortran or C. And indeed, there must be something wrong with the C implementation. Pull requests with improvements are welcome:

https://github.com/marblestation/benchmark-leapfrog

View on HN

No, there is something wrong with the Rust version. I added println!("{:?}",x); to the end, and now I get 134 second runtime.

Also the output is [[NaN, NaN, NaN], [NaN, NaN, NaN]], which is a bit worrying...

All the particles in the simulation start at (0, 0, 0) so gravity is infinite, and the whole computation is operating on `NaN`s.

Not sure how much this affects the benchmark, but it'd probably be smart to randomise the starting positions.

Since the masses are also zero, the gravity is actually NaN.

Operating on NaN is hugely slower than normal floating point numbers. You're hitting a slowpath in the processor's floating point logic.

That is fixed now, conclusions are still valid :-) Thanks!

Interesting, the code looks more similar than I expected, yet the results are very different! Could it be that the difference is due to aliasing rules? It would be interesting to see what happens after adding a few restrict keywords here and there...

You would think that the presence of any unsafe block in the program's text, or even linkage with libc could result in (legitimate, non UB) aliasing in lots of code. Though I suppose that the private-linkage-by-default could help drastically reduce the scope it has to consider, maybe in some cases it can safely say that data is not aliased.

GCC produces almost 30% more instructions for the C version at -O3 level as opposed to -O2.

Clang produces practically the same between the two levels.

On OS X, so can't test if this actually makes a performance difference.

On my laptop (i7-5500U), I get the following timings (always with -march=native or -xHOST):

    GCC 6.3, -Ofast:      5.93s
    GCC 6.3, -O3:        93.06s
    GCC 6.3, -O2:       134.43s
    Clang 3.9, -O3:     346.92s
    Clang 3.9, -Ofast:    5.87s
    Intel 15.0, -O3:    110.84s
    Intel 15.0, -Ofast: 106.88s

The Intel compiler is relatively old, but mostly it seems to be a case of IEEE 754 conformance -- if enabled, things take longer, if disabled, they’re (probably) as fast in C as in Rust.

>On OS X, so can't test if this actually makes a performance difference.

The `time` command is part of base OS X.

But gcc is not.

In my reading of the comment it seemed to imply that the commenter already had both clang and gcc installed on their computer since they were talking about the amount of instructions produced by each. Perhaps I misunderstood?

I'm not sure, to be honest. I just assumed they were running GCC in a VM, but actually there was no real reason for me to assume that.

Reply on news.ycombinator.com