Hacker News Reader

Comment by reitzensteinm | Hacker News Reader

There's something wrong there. Either a corner case, or they are multithreading and vectorizing the Rust/Fortran but not the C.

Which would be the equivalent of writing a comparison between a sledgehammer and jackhammer, without turning the latter on.

View on HN

The code is available here:

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

It would be great if somebody have a fresh look at the C version, since I completely agree that it is not normal that its execution time is so far away from Fortran or Rust.

On my system:

  gcc -O3
  1m40.302s

  gcc -O3 -ffast-math
  0m5.110s

  rustc -C opt-level=3
  0m9.278s

gcc (GCC) 6.3.1 20170109

rustc 1.15.1 (021bd294c 2017-02-08)

Edit: Looking into this a bit more, I think 'rustc -C opt-level=3' is optimizing out the actual integration. If I put a println!("{}", x[0][0]) at the end, I end up with 1m43s. Not sure what 'gcc -O3 -ffast-math' is doing; I haven't looked at the disassembly.

Fantastic, thanks!!!

-ffast-math might be a bit cheating here, for scientific work it's not always applicable. Unless rustc uses fast math by default? That would be weird.

It's surprising that gcc does such a poor job at -O3 though.

Rust doesn't even have a way to turn on fastmath, AFAIK.

It does, for individual operations: https://doc.rust-lang.org/std/?search=fast

> If I put a println!("{}", x[0][0]) at the end, I end up with 1m43s.

Yes, without that it's basically cheating. There is now a GitHub issue: https://github.com/marblestation/benchmark-leapfrog/issues/6

The submitter writes: "final output [for Rust] is 134 seconds, and also the output is [[NaN, NaN, NaN], [NaN, NaN, NaN]] (batman)"

Reply on news.ycombinator.com