7 ms·

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): ht

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 https://github.com/marblestation/benchmark-leapfrog And indeed, Fortran has decades of advantage in terms of libraries.

llukas 10y ago
C implementation doesnt use restrict pointers. It is shooting itself in the foot.
acqq 10y ago
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<n_particles;i++){ x[i][0] += half_time_step * v[i][0]; ... int main(int argc, char* argv[]) { const int n_particles = 2; ... while(time <= time_limit) { integrator_leapfrog_part1(n_particles, x, v, half_time_step); The Rust code: const N_PARTICLES: usize = 2; ... fn main() { ... while time <= time_limit { integrator_leapfrog_part1(N_PARTICLES, &mut x, &v, half_time_step); ... fn integrator_leapfrog_part1(n_particles: usize, x: &mut [[f64; 3]; N_PARTICLES], v: &[[f64; 3]; N_PARTICLES], half_time_step: f64) { for i in 0..n_particles { x[i][0] += half_time_step * v[i][0]; The way I understand it, with the C code the compiler during the compilation of the function doesn't know the size of the array, and with the Rust code it does, it is explicitly written? I refer to the difference between the capital letter constant and the plain variable. What would happen if the C compiler only knew that much too? that is, having the presence of the N_PARTICLES in all declarations? I can also imagine that just adding the proper compiler and linker options for C, not used in the makefile, can maybe give the benefit of that constant propagation in this particular case? I mean what happens when the "-flto" is added? The N-Body on this site, with other implementations, has clearly faster C than Rust: https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=nbody https://benchmarksgame.alioth.debian.org/u64q/performance.ph...
- kibwen 10y ago
  >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
  - acqq 10y ago
    The programs on the site fit the rules defined on it, and the rules include the verification of the results: https://benchmarksgame.alioth.debian.org/why-measure-toy-benchmark-programs.html 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.
    - kibwen 10y ago
      > The programs on the site fit the rules defined on it, and the rules include the verification of the results I'm not sure what you're refuting? Verifying that the results match is a necessary but insufficient quality for ensuring comparability. If the algorithm could be the same in each language but isn't (e.g. quicksort vs. bogosort), then that's not a valid comparison if your objective is to determine the overhead imposed by the language implementation itself (and if you're not trying to determine language implementation overhead, then what are you measuring?). Likewise if the implementation details could be the same in each language but aren't (e.g. if one uses 64-bit integers and the other uses 32-bit integers). The computer language benchmarks game was initially conceived to determine a ballpark for how slow interpreted and managed languages are compared to C. Quantifying the overhead of interpreters and runtimes is its raison d'etre, and it shows. When it comes to comparing low-level systems languages that have no runtime to speak of, the best it can do is attempt to quantify the quality of each backend's code generator (it's a missed opportunity that it doesn't include Clang for comparison with GCC). (And yes, I understand that the benchmarks game contains repeated massive disclaimers that people should not take the performance results as a means of serious comparison. Internet commentators remain undeterred.) If you're just trying to argue that the methodology used in the OP is poor, then obviously we're in agreement (was there ever any doubt?).

llukas 10y ago

C implementation doesnt use restrict pointers. It is shooting itself in the foot.

acqq 10y ago

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<n_particles;i++){ x[i][0] += half_time_step * v[i][0]; ... int main(int argc, char* argv[]) { const int n_particles = 2; ... while(time <= time_limit) { integrator_leapfrog_part1(n_particles, x, v, half_time_step); The Rust code: const N_PARTICLES: usize = 2; ... fn main() { ... while time <= time_limit { integrator_leapfrog_part1(N_PARTICLES, &mut x, &v, half_time_step); ... fn integrator_leapfrog_part1(n_particles: usize, x: &mut [[f64; 3]; N_PARTICLES], v: &[[f64; 3]; N_PARTICLES], half_time_step: f64) { for i in 0..n_particles { x[i][0] += half_time_step * v[i][0]; The way I understand it, with the C code the compiler during the compilation of the function doesn't know the size of the array, and with the Rust code it does, it is explicitly written? I refer to the difference between the capital letter constant and the plain variable. What would happen if the C compiler only knew that much too? that is, having the presence of the N_PARTICLES in all declarations? I can also imagine that just adding the proper compiler and linker options for C, not used in the makefile, can maybe give the benefit of that constant propagation in this particular case? I mean what happens when the "-flto" is added? The N-Body on this site, with other implementations, has clearly faster C than Rust: https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=nbody https://benchmarksgame.alioth.debian.org/u64q/performance.ph...

kibwen 10y ago
>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
- acqq 10y ago
  The programs on the site fit the rules defined on it, and the rules include the verification of the results: https://benchmarksgame.alioth.debian.org/why-measure-toy-benchmark-programs.html 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.
  - kibwen 10y ago
    > The programs on the site fit the rules defined on it, and the rules include the verification of the results I'm not sure what you're refuting? Verifying that the results match is a necessary but insufficient quality for ensuring comparability. If the algorithm could be the same in each language but isn't (e.g. quicksort vs. bogosort), then that's not a valid comparison if your objective is to determine the overhead imposed by the language implementation itself (and if you're not trying to determine language implementation overhead, then what are you measuring?). Likewise if the implementation details could be the same in each language but aren't (e.g. if one uses 64-bit integers and the other uses 32-bit integers). The computer language benchmarks game was initially conceived to determine a ballpark for how slow interpreted and managed languages are compared to C. Quantifying the overhead of interpreters and runtimes is its raison d'etre, and it shows. When it comes to comparing low-level systems languages that have no runtime to speak of, the best it can do is attempt to quantify the quality of each backend's code generator (it's a missed opportunity that it doesn't include Clang for comparison with GCC). (And yes, I understand that the benchmarks game contains repeated massive disclaimers that people should not take the performance results as a means of serious comparison. Internet commentators remain undeterred.) If you're just trying to argue that the methodology used in the OP is poor, then obviously we're in agreement (was there ever any doubt?).