Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What can Rust do for astrophysics?

arxiv.org

Post reply on HN
Print view View original

21–30 of 115 posts

Re: What can Rust do for astrophysics?

#21

Post by [deleted] »

marblestation wrote: post #10
ktta wrote: post #3

It's crazy for me to see that C is much slower than rust. I'm almost sure that there's something wrong there. In table 1 Rust Fortran C Go 0m13.660s 0m14.640s 2m32.910s 4m26.240s They did have a note that C could be faster if language specific features could be used. Is rust really that performant compared to C? Or did they neglect to even bother checking C's performance?

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

[deleted]

Re: What can Rust do for astrophysics?

#22

Post by eriknstr »

berkut wrote: post #11
marblestation wrote: post #10

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

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.

>On OS X, so can't test if this actually makes a performance difference.

The `time` command is part of base OS X.

Re: What can Rust do for astrophysics?

#23

Post by llukas »

marblestation wrote: post #7
acqq wrote: post #2

Where are the links to the sources and is there a chance to compare the versions (Fortran vs Rust doing the same calculations)? I wasn't able to find them. Where is the discussion of the library availability? The libraries for Fortran are maintained and improved during the decades?

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.

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

Re: What can Rust do for astrophysics?

#24

Post by CJefferson »

marblestation wrote: post #10
ktta wrote: post #3

It's crazy for me to see that C is much slower than rust. I'm almost sure that there's something wrong there. In table 1 Rust Fortran C Go 0m13.660s 0m14.640s 2m32.910s 4m26.240s They did have a note that C could be faster if language specific features could be used. Is rust really that performant compared to C? Or did they neglect to even bother checking C's performance?

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

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

Re: What can Rust do for astrophysics?

#25

Post by gpderetta »

panic wrote: post #16
ktta wrote: post #3

It's crazy for me to see that C is much slower than rust. I'm almost sure that there's something wrong there. In table 1 Rust Fortran C Go 0m13.660s 0m14.640s 2m32.910s 4m26.240s They did have a note that C could be faster if language specific features could be used. Is rust really that performant compared to C? Or did they neglect to even bother checking C's performance?

For me, clang -O3 optimizes the main function into this single loop: LBB3_1: addsd %xmm1, %xmm0 addsd %xmm1, %xmm0 ucomisd %xmm0, %xmm2 jae LBB3_1 %xmm0 begins at 0, %xmm1 is 0.04, and %xmm2 is 3.6525E+8. In other words, it's measuring how long it takes to count to 3.6525E+8 by adding 0.04 repeatedly. LLVM (which both Rust and clang use as a backend) optimizes away the actual work of the program. GCC doesn't seem to…

I.e the program has no side effects so it can be completely optimized away.

Never trust a benchmark you didn't falsify yourself.

Re: What can Rust do for astrophysics?

#26

Post by acqq »

marblestation wrote: post #7
acqq wrote: post #2

Where are the links to the sources and is there a chance to compare the versions (Fortran vs Rust doing the same calculations)? I wasn't able to find them. Where is the discussion of the library availability? The libraries for Fortran are maintained and improved during the decades?

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

Re: What can Rust do for astrophysics?

#27

Post by one-more-minute »

CJefferson wrote: post #24
marblestation wrote: post #10

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

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.

Re: What can Rust do for astrophysics?

#28

Post by tom_mellior »

walrus wrote: post #12
marblestation wrote: post #8

Earlier quoted context omitted.

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.

> 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)"

Re: What can Rust do for astrophysics?

#29

Post by fhars »

one-more-minute wrote: post #27
CJefferson wrote: post #24

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.

Since the masses are also zero, the gravity is actually NaN.

Re: What can Rust do for astrophysics?

#30

Post by J0-nas »

I don't know the astrophysics domain at all but shouldn't there be more arguments for Go?

* Safer than C

* Almost as fast as C

* Good concurrency support

* High productivity due to simple abstractions and good tooling

Is the downside of a GC language really relevant? Does astrophysics suffer from "stop the world interrupts" or is it just because of the performance? The Go GC is already really fast.

Post reply on HN