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