13 ms·

What can Rust do for astrophysics?

130 points by privong 10y ago

acqq 10y ago
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?
- marblestation 10y ago
  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?).
ktta 10y ago
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?
- reitzensteinm 10y ago
  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.
  - marblestation 10y ago
    The code is available here: https://github.com/marblestation/benchmark-leapfrog 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.
    - walrus 10y ago
      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.
      - marblestation 10y ago
        Fantastic, thanks!!!
      - simias 10y ago
srwalker101 10y ago
For those who are looking at doing data analysis with Rust in astrophysics, I have a crate fitsio (https://crates.io/crates/fitsio https://crates.io/crates/fitsio) which wraps cfitsio into rust, allowing the reading and writing of .fits files.
- Avshalom 10y ago
  Nice. I mean I didn't wanna say but when I saw the headline my first thought was "basically nothing if you don't have a fits library"
- sbinet 10y ago
  and for those doing the same but in Go: https://github.com/astrogo/fitsio https://github.com/astrogo/fitsio (a pure Go version)
J0-nas 10y ago
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.
- easytiger 10y ago
  Why would one care about safety in a science context?
  - mike-cardwell 10y ago
    Because they want the correct results?
    - claudius 10y ago
      During the past years of coding in C++ in the context of tensor networks in condensed matter physics, I have never encountered the case where a programming error which would have been caught in Rust or Go lead to incorrect results. Yes, there were plenty of crashes and plenty of hard to debug issues, but it was always obvious that something was wrong way before any results were calculated/printed/output.
      - ZoFreX 10y ago
        I was thinking the same thing when I read this quote: > For instance, a common source of error is the access to invalid memory regions, which produces random execution behaviors and affects the scientific interpretation of the results. Such errors are astronomically more likely to cause crashes than silent errors in calculations.
      - mike-cardwell 10y ago
        Does your statement in some way address my point that "wanting correct results" is a legitimate reason to "care about safety in a science context" ?
dottrap 10y ago
Is the code in gravity_calculate_acceleration correct? I think 'j' will always be 0 in the inner-loop, which seems to defeat the purpose of having a j variable. void gravity_calculate_acceleration(int n_particles, double m[], double x[][3], double a[][3]) { double G = 6.6742367e-11; // m^3.kg^-1.s^-2 for (int i=0; i<n_particles; i++){ a[i][0] = 0; a[i][1] = 0; a[i][2] = 0; for (int j=0; i<n_particles; i++){ if (j == i) { continue; } double dx = x[i][0] - x[j][0]; double dy = x[i][0] - x[j][0]; double dz = x[i][0] - x[j][0]; double r = sqrt(dx*dx + dy*dy + dz*dz); double prefact = -G/(r*r*r) * m[j]; a[i][0] += prefact * dx; a[i][1] += prefact * dy; a[i][2] += prefact * dz; } } }
- michaf 10y ago
  This seems to have been fixed 3 hours ago: https://github.com/marblestation/benchmark-leapfrog/commit/c51d95dad0a83d6c3cb5f2868896da3bfa46e158 https://github.com/marblestation/benchmark-leapfrog/commit/c...
  - nhatcher 10y ago
    Yes, but m is zero anyway.
    - michaf 10y ago
      You are correct. It seems they really should double-check their implementation for producing meaningful results before running bechmarks on it...
      - deleted 10y ago
        [deleted]
ptero 10y ago
Just my 2c -- it is a potentially interesting article, but two things have to be fixed: 1. Compile C version with better optimization flags or ask an expert to tweak it for faster performance. 2. Include sample run on some known / meaningful data to test that software runs correctly (not only fast). IMO rust doesn't have to be faster than C to make a valuable article. If it is as fast or almost as fast it is still a good data point.
- tom_mellior 10y ago
  > Compile C version with better optimization flags or ask an expert to tweak it for faster performance. Part of the point they are trying to make is that you don't need to be an expert to reap performance benefits in certain languages. They explicitly state that they did not do things that C experts would know how to do. This is pretty reasonable in the context of astrophysics. The whole idea of the thing is that if there is a language that allows you to write faster code than C without having to "ask an expert to tweak it", you will be more productive using that language. That said, your point 2 is entirely valid; the paper fails to demonstrate pretty much all of its claims, and it never makes a case for needing Rust's safe dynamic memory allocation features in a program that doesn't use dynamic allocation at all. For whatever it's worth, the astrophysicists I most recently talked to wrote their simulations in Python (with SciPy or similar) or even something called IDL: https://en.wikipedia.org/wiki/IDL_(programming_language) https://en.wikipedia.org/wiki/IDL_(programming_language) and they also tend to have mad Bash skills for glueing different data-processing programs together.
  - ptero 10y ago
    You have a good criticism on my #1. I should drop "ask the expert" part but still maintain that when writing numerical computation software checking for compile flags is a reasonable request. Leave code as is, but still try -O3 / -Ofast. At this point it is not the language expertise, but knowing about your tools.
    - tom_mellior 10y ago
      Agreed, mostly :-) The paper does state that they used -O3.
Devid2014 10y ago
https://github.com/marblestation/benchmark-leapfrog 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 library for example ? To show the difference . Also this is naive O(N^2) sim that could be speed up using Fast multipole method (FMM), but of course this would be much more complicated to do this in Rust or Go as in C++.
- thebooktocome 10y ago
  I wouldn't bet that FMM is more complicated to implement in Rust as in C++.
  - Devid2014 10y ago
    For me Rust has a lot of potential to write more secure code in places where it is needed but astrophysics is may be not one of them. Not sure about language it self, my knowledge about Rust is limited. But st is at least harder because we already have optimized libraries that can do this in C++. Do some one know such library for Rust ? It would be great too look at it.
- acqq 10y ago
  Indeed, the code that was initially published apparently didn't even output any results, and that can be optimized to "do nothing, return"?
- semi-extrinsic 10y ago
  As others have pointed out, adding insult to injury, in the Rust version the bulk of the actual calculation is optimized out completely! Adding a print at the end increases the runtime by an order of magnitude. The Rust community is actively hurt by people doing things like this, no-one takes this type of work seriously. Edit: please come back when you've replicated and validated at least something like a basic, well-understood finite difference solver of single-phase incompressible Navier-Stokes, and shown that it's either equivalently fast and much easier code, or significantly faster (very unlikely). Do note that a readable Fortran version is going to be ~400 lines, so there's not a terribly large room for improvement. Also, we already have a good language that gives us slower and much easier code, namely Python.
dikaiosune 10y ago
A little less than a year ago I worked on a bioinformatics project in rust, and I think it came out very well. My perception was that bio is a field where most practitioners rely on high speed code written by someone else that can be called from their perl or python code. I see something very empowering with rust, where people can write high performance analysis without having to shoehorn their workload into an existing toolkit or framework. That said, while I'm really excited to see rust go more places, astrophysics seems like one of very few fields where practitioners learn a high performance language as a matter of course, and so rust may have a less empowering effect for them. I would wager that after paying the upfront cost to learn it, students and researchers may see improved iteration time from fewer bugs. But it seems like rust may have an incremental improvement to offer which is not as powerful as the transformative nature of its potential in other computationally intensive fields.
ced 10y ago
As someone with no Rust experience... a) access to invalid memory regions, b) dangling pointers and attempts to free already freed memory, c) memory leaks and, d) race conditions. The first three benefits also come with essentially any GC'ed language. d) is interesting. What are the costs that come with such a guarantee? Presumably it prohibits certain kinds of parallelism? Are the ownership/borrowing mechanics interesting programming tools, or are they a hindrance? People talk a lot about static typing, and I can see the benefits for critical/user-facing applications, but not for numerical code. The nightmare with numerical code is finding out that I forgot a minus sign somewhere, and that it invalidates my last 6 months of published results.
- eridius 10y ago
  > Presumably it prohibits certain kinds of parallelism? Actually it enables parallelism you couldn't do before, because now you're confident the compiler will prove that what you're doing is safe.
- steveklabnik 10y ago
  > Are the ownership/borrowing mechanics interesting programming tools, or are they a hindrance? Like any sort of static analysis, some see them as a tool, some see them as a hindrance ;) > also come with essentially any GC'ed language. Ownership and borrowing can extend to arbitrary resources, not just memory. Also, C and D aren't correct; while Rust helps with memory leaks, it absolutely does not prevent them, and Rust prevents _data races_, a specific form of race condition, but cannot prevent race conditions generally.

130 points by privong 10y ago

acqq 10y ago

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?

marblestation 10y ago
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?).

ktta 10y ago

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?

reitzensteinm 10y ago
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.
- marblestation 10y ago
  The code is available here: https://github.com/marblestation/benchmark-leapfrog 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.
  - walrus 10y ago
    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.
    - marblestation 10y ago
      Fantastic, thanks!!!
    - simias 10y ago

srwalker101 10y ago

For those who are looking at doing data analysis with Rust in astrophysics, I have a crate fitsio (https://crates.io/crates/fitsio https://crates.io/crates/fitsio) which wraps cfitsio into rust, allowing the reading and writing of .fits files.

Avshalom 10y ago
Nice. I mean I didn't wanna say but when I saw the headline my first thought was "basically nothing if you don't have a fits library"
sbinet 10y ago
and for those doing the same but in Go: https://github.com/astrogo/fitsio https://github.com/astrogo/fitsio (a pure Go version)

J0-nas 10y ago

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.

easytiger 10y ago
Why would one care about safety in a science context?
- mike-cardwell 10y ago
  Because they want the correct results?
  - claudius 10y ago
    During the past years of coding in C++ in the context of tensor networks in condensed matter physics, I have never encountered the case where a programming error which would have been caught in Rust or Go lead to incorrect results. Yes, there were plenty of crashes and plenty of hard to debug issues, but it was always obvious that something was wrong way before any results were calculated/printed/output.
    - ZoFreX 10y ago
      I was thinking the same thing when I read this quote: > For instance, a common source of error is the access to invalid memory regions, which produces random execution behaviors and affects the scientific interpretation of the results. Such errors are astronomically more likely to cause crashes than silent errors in calculations.
    - mike-cardwell 10y ago
      Does your statement in some way address my point that "wanting correct results" is a legitimate reason to "care about safety in a science context" ?

dottrap 10y ago

Is the code in gravity_calculate_acceleration correct? I think 'j' will always be 0 in the inner-loop, which seems to defeat the purpose of having a j variable. void gravity_calculate_acceleration(int n_particles, double m[], double x[][3], double a[][3]) { double G = 6.6742367e-11; // m^3.kg^-1.s^-2 for (int i=0; i<n_particles; i++){ a[i][0] = 0; a[i][1] = 0; a[i][2] = 0; for (int j=0; i<n_particles; i++){ if (j == i) { continue; } double dx = x[i][0] - x[j][0]; double dy = x[i][0] - x[j][0]; double dz = x[i][0] - x[j][0]; double r = sqrt(dx*dx + dy*dy + dz*dz); double prefact = -G/(r*r*r) * m[j]; a[i][0] += prefact * dx; a[i][1] += prefact * dy; a[i][2] += prefact * dz; } } }

michaf 10y ago
This seems to have been fixed 3 hours ago: https://github.com/marblestation/benchmark-leapfrog/commit/c51d95dad0a83d6c3cb5f2868896da3bfa46e158 https://github.com/marblestation/benchmark-leapfrog/commit/c...
- nhatcher 10y ago
  Yes, but m is zero anyway.
  - michaf 10y ago
    You are correct. It seems they really should double-check their implementation for producing meaningful results before running bechmarks on it...
    - deleted 10y ago
      [deleted]

ptero 10y ago

Just my 2c -- it is a potentially interesting article, but two things have to be fixed: 1. Compile C version with better optimization flags or ask an expert to tweak it for faster performance. 2. Include sample run on some known / meaningful data to test that software runs correctly (not only fast). IMO rust doesn't have to be faster than C to make a valuable article. If it is as fast or almost as fast it is still a good data point.

tom_mellior 10y ago
> Compile C version with better optimization flags or ask an expert to tweak it for faster performance. Part of the point they are trying to make is that you don't need to be an expert to reap performance benefits in certain languages. They explicitly state that they did not do things that C experts would know how to do. This is pretty reasonable in the context of astrophysics. The whole idea of the thing is that if there is a language that allows you to write faster code than C without having to "ask an expert to tweak it", you will be more productive using that language. That said, your point 2 is entirely valid; the paper fails to demonstrate pretty much all of its claims, and it never makes a case for needing Rust's safe dynamic memory allocation features in a program that doesn't use dynamic allocation at all. For whatever it's worth, the astrophysicists I most recently talked to wrote their simulations in Python (with SciPy or similar) or even something called IDL: https://en.wikipedia.org/wiki/IDL_(programming_language) https://en.wikipedia.org/wiki/IDL_(programming_language) and they also tend to have mad Bash skills for glueing different data-processing programs together.
- ptero 10y ago
  You have a good criticism on my #1. I should drop "ask the expert" part but still maintain that when writing numerical computation software checking for compile flags is a reasonable request. Leave code as is, but still try -O3 / -Ofast. At this point it is not the language expertise, but knowing about your tools.
  - tom_mellior 10y ago
    Agreed, mostly :-) The paper does state that they used -O3.

Devid2014 10y ago

https://github.com/marblestation/benchmark-leapfrog 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 library for example ? To show the difference . Also this is naive O(N^2) sim that could be speed up using Fast multipole method (FMM), but of course this would be much more complicated to do this in Rust or Go as in C++.

thebooktocome 10y ago
I wouldn't bet that FMM is more complicated to implement in Rust as in C++.
- Devid2014 10y ago
  For me Rust has a lot of potential to write more secure code in places where it is needed but astrophysics is may be not one of them. Not sure about language it self, my knowledge about Rust is limited. But st is at least harder because we already have optimized libraries that can do this in C++. Do some one know such library for Rust ? It would be great too look at it.
acqq 10y ago
Indeed, the code that was initially published apparently didn't even output any results, and that can be optimized to "do nothing, return"?
semi-extrinsic 10y ago
As others have pointed out, adding insult to injury, in the Rust version the bulk of the actual calculation is optimized out completely! Adding a print at the end increases the runtime by an order of magnitude. The Rust community is actively hurt by people doing things like this, no-one takes this type of work seriously. Edit: please come back when you've replicated and validated at least something like a basic, well-understood finite difference solver of single-phase incompressible Navier-Stokes, and shown that it's either equivalently fast and much easier code, or significantly faster (very unlikely). Do note that a readable Fortran version is going to be ~400 lines, so there's not a terribly large room for improvement. Also, we already have a good language that gives us slower and much easier code, namely Python.

dikaiosune 10y ago

A little less than a year ago I worked on a bioinformatics project in rust, and I think it came out very well. My perception was that bio is a field where most practitioners rely on high speed code written by someone else that can be called from their perl or python code. I see something very empowering with rust, where people can write high performance analysis without having to shoehorn their workload into an existing toolkit or framework. That said, while I'm really excited to see rust go more places, astrophysics seems like one of very few fields where practitioners learn a high performance language as a matter of course, and so rust may have a less empowering effect for them. I would wager that after paying the upfront cost to learn it, students and researchers may see improved iteration time from fewer bugs. But it seems like rust may have an incremental improvement to offer which is not as powerful as the transformative nature of its potential in other computationally intensive fields.

ced 10y ago

As someone with no Rust experience... a) access to invalid memory regions, b) dangling pointers and attempts to free already freed memory, c) memory leaks and, d) race conditions. The first three benefits also come with essentially any GC'ed language. d) is interesting. What are the costs that come with such a guarantee? Presumably it prohibits certain kinds of parallelism? Are the ownership/borrowing mechanics interesting programming tools, or are they a hindrance? People talk a lot about static typing, and I can see the benefits for critical/user-facing applications, but not for numerical code. The nightmare with numerical code is finding out that I forgot a minus sign somewhere, and that it invalidates my last 6 months of published results.

eridius 10y ago
> Presumably it prohibits certain kinds of parallelism? Actually it enables parallelism you couldn't do before, because now you're confident the compiler will prove that what you're doing is safe.
steveklabnik 10y ago
> Are the ownership/borrowing mechanics interesting programming tools, or are they a hindrance? Like any sort of static analysis, some see them as a tool, some see them as a hindrance ;) > also come with essentially any GC'ed language. Ownership and borrowing can extend to arbitrary resources, not just memory. Also, C and D aren't correct; while Rust helps with memory leaks, it absolutely does not prevent them, and Rust prevents _data races_, a specific form of race condition, but cannot prevent race conditions generally.