71–80 of 115 posts
https://github.com/marblestation/benchmark-leapfrog This are not valid benchmarks at all. What is the point to run N-Body sim with all particles set to 0.0 ? Where is the result of the sim ? Why it will be not validated at all ? To make this look like real benchmark one will need to use the same start condition and then validate that result for all languages is the same. It would be great to have C++ code using Eigen…
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
-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.
Earlier quoted context omitted.
I don't belive in this result! C slower than Rust in 11 times!!! Are they kidding?! http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... -- in this benchmarks C in most cases faster than Rust, but only in few they have the same performance.
In most of those benchmarks rust is slower because it lacks SIMD support, not because of compiler optimizations.
Earlier quoted context omitted.
You can find the code for the simple N-Body implemented in different languages here (the more advanced N-Body version with tides has not been released yet): https://github.com/marblestation/benchmark-leapfrog And indeed, Fortran has decades of advantage in terms of libraries.
It's 64 lines of rs, hardly enough to demonstrate anything for the real use, and it's suspiciously badly written, if I understand correctly: The C code: void integrator_leapfrog_part1(int n_particles, double x[][3], double v[][3], double half_time_step){ for (int i=0;i The Rust code: const N_PARTICLES: usize = 2; ... fn main() { ... while time The way I understand it, with the C code the compiler during the compilati…
As noted elsewhere in here, the C implementation is using SSE, whereas the Rust implementation isn't. It's just as much of an unfair comparison as the one you're describing. :P
Earlier quoted context omitted.
In most of those benchmarks rust is slower because it lacks SIMD support, not because of compiler optimizations.
Or rather, Rust is slower on those because SIMD is currently only supported on nightly, and the benchmarks game chooses to use stable Rust exclusively.
Earlier quoted context omitted.
It's 64 lines of rs, hardly enough to demonstrate anything for the real use, and it's suspiciously badly written, if I understand correctly: The C code: void integrator_leapfrog_part1(int n_particles, double x[][3], double v[][3], double half_time_step){ for (int i=0;i The Rust code: const N_PARTICLES: usize = 2; ... fn main() { ... while time The way I understand it, with the C code the compiler during the compilati…
>The N-Body on this site As noted elsewhere in here, the C implementation is using SSE, whereas the Rust implementation isn't. It's just as much of an unfair comparison as the one you're describing. :P
https://benchmarksgame.alioth.debian.org/why-measure-toy-ben...
The OP doesn't even specify the rules for its own benchmark, as far as I understand doesn't verify the results? People here get NaNs?
If the NaNs are produced as results, then the OP code is not measuring the speed of calculations at all but the speed of the failed calculations. Which is especially problematic as the main argument is "attractive for the scientific community" "it guarantees memory safety." Which is presented as good because not having it "can produce random behaviors and affect the scientific interpretation of the results." If the result here is NaN the calculation doesn't even have to be performed after the first NaN that affects the result appears, as anything + NaN is NaN etc.
Edit: kibwen, did I write somewhere that I "refute" something? I gave a link to the rationale behind the "benchmarksgame" site. The rest is about the OP, surely not about your post.
Earlier quoted context omitted.
I think you misunderstand what "safety" refers to in the context of programming. It's not about flaws in your program being attacked, it's about writing correct programs.
I think you are completely missing the point here. The HPC world is mostly concerned with the speed at which you get results, safety means almost nothing in this domain. What people typically do is to test their code against known input/output and check the relative error. It is easier to debug and improve a fast program when you can have some result in 1 day versus same algorithm implemented in a slower language tha…
https://github.com/marblestation/benchmark-leapfrog This are not valid benchmarks at all. What is the point to run N-Body sim with all particles set to 0.0 ? Where is the result of the sim ? Why it will be not validated at all ? To make this look like real benchmark one will need to use the same start condition and then validate that result for all languages is the same. It would be great to have C++ code using Eigen…
Earlier quoted context omitted.
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
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...