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

81–90 of 115 posts

Re: What can Rust do for astrophysics?

#81

Post by semi-extrinsic »

Devid2014 wrote: post #54

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…

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.

Re: What can Rust do for astrophysics?

#82

Post by burntsushi »

tom_mellior wrote: post #50
ptero wrote: post #45

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…

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

> Rust's safe dynamic memory allocation features

Rust's safety features aren't tied at all to dynamic memory allocation. You can write a Rust program with pointers (into the stack, for example) with no dynamic memory allocation at all and still benefit immensely from the safety features.

Re: What can Rust do for astrophysics?

#83

Post by kibwen »

acqq wrote: post #77
kibwen wrote: post #75

Earlier quoted context omitted.

>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

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-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 s…

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

Re: What can Rust do for astrophysics?

#84

Post by ced »

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.

Re: What can Rust do for astrophysics?

#85

Post by dbaupp »

kibwen wrote: post #73
simias wrote: post #19

Earlier quoted context omitted.

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

Rust doesn't even have a way to turn on fastmath, AFAIK.

It does, for individual operations: https://doc.rust-lang.org/std/?search=fast

Re: What can Rust do for astrophysics?

#86

Post by dbaupp »

pjmlp wrote: post #76
kibwen wrote: post #74

Earlier quoted context omitted.

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.

I also don't work with VS Release Candidates for production code, as such I think it is faire to use only stable Rust.

From what I've seen, most of the Rust community agrees that using stable a perfectly fine choice; kibwen is offering context, not complaining.

Re: What can Rust do for astrophysics?

#87

Post by pjmlp »

dbaupp wrote: post #86
pjmlp wrote: post #76

Earlier quoted context omitted.

I also don't work with VS Release Candidates for production code, as such I think it is faire to use only stable Rust.

From what I've seen, most of the Rust community agrees that using stable a perfectly fine choice; kibwen is offering context, not complaining.

I agree with him, I express myself badly.

Re: What can Rust do for astrophysics?

#88

Post by eridius »

ced wrote: post #84

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 inter…

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

Re: What can Rust do for astrophysics?

#89

Post by Devid2014 »

thebooktocome wrote: post #71
Devid2014 wrote: post #54

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…

I wouldn't bet that FMM is more complicated to implement in Rust as in C++.

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.

Re: What can Rust do for astrophysics?

#90

Post by steveklabnik »

ced wrote: post #84

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 inter…

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

Post reply on HN