5 ms·

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

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 https://github.com/marblestation/benchmark-leapfrog

berkut 10y ago
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.
- claudius 10y ago
  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.
- eriknstr 10y ago
  >On OS X, so can't test if this actually makes a performance difference. The `time` command is part of base OS X.
  - Sean1708 10y ago
    But gcc is not.
    - eriknstr 10y ago
      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?
      - Sean1708 10y ago
        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.
arximboldi 10y ago
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...
- wyldfire 10y ago
  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.
deleted 10y ago
[deleted]
CJefferson 10y ago
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...
- one-more-minute 10y ago
  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.
  - fhars 10y ago
    Since the masses are also zero, the gravity is actually NaN.
  - FeepingCreature 10y ago
    Operating on NaN is hugely slower than normal floating point numbers. You're hitting a slowpath in the processor's floating point logic.
- marblestation 10y ago
  That is fixed now, conclusions are still valid :-) Thanks!

berkut 10y ago

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.

claudius 10y ago
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.
eriknstr 10y ago
>On OS X, so can't test if this actually makes a performance difference. The `time` command is part of base OS X.
- Sean1708 10y ago
  But gcc is not.
  - eriknstr 10y ago
    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?
    - Sean1708 10y ago
      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.

arximboldi 10y ago

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

wyldfire 10y ago
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.

deleted 10y ago

[deleted]

CJefferson 10y ago

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

one-more-minute 10y ago
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.
- fhars 10y ago
  Since the masses are also zero, the gravity is actually NaN.
- FeepingCreature 10y ago
  Operating on NaN is hugely slower than normal floating point numbers. You're hitting a slowpath in the processor's floating point logic.
marblestation 10y ago
That is fixed now, conclusions are still valid :-) Thanks!