31–40 of 115 posts
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.
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.
Why would one care about safety in a science context?
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.
That's the key point. Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C.
A grad student (if paid properly) costs maybe 60k €/year. In comparison, we regularly spend more than 250k on new and faster computers, not including maintenance, the electricity bill etc. If you can make software even 50% faster by increasing development time, this is nearly always worth it in an academic setting. Note that the benchmark implementation shown here is a very simple example, normally computing jobs take days to weeks (multiplied by however many cores you can sensibly use) of CPU time.
Decreasing runtime also increases productivity a lot, since the turnaround time becomes shorter; waiting 3 versus 6 weeks for results is a noticeable difference.
Additionally, these tools rarely have safety concerns: In my own code, there is no "untrusted user input". There is correct user input (good) and incorrect user input (mostly it will crash, with common mistakes it will try to notify the user). Safety is handled by the operating system (such that you can’t overwrite someone else’s data, for example).
This means that the only advantage Go could have over C/C++ in academia is the "good concurrency support". However, concurrency in HPC is usually handled via OpenMP (shared memory) or MPI (distributed memory) parallelisation. This takes a while to get used to, but is very different (and in a sense much easier) than e.g. the typical case for a web server, where you wish to serve as many users as possible at the same time using as little CPU time as possible – a busily waiting loop is horrible in the latter case but perfectly fine in the former (under some circumstances).
So overall, languages are not interesting in the academic HPC crowd if they sacrifice speed for anything, which, incidentally, makes Rust also interesting, because that is precisely not the case (apparently, under some circumstances, etc.pp.).
Earlier quoted context omitted.
Why would one care about safety in a science context?
Because they want the correct results?
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; iIt'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…
printf("x[0][0]=%f\n", x[0][0]);
Benchmarking is hard.
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.
> * Almost as fast as C That's the key point. Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C. A grad student (if paid properly) costs maybe 60k €/year. In comparison, we regularly spend more than 250k on new and faster computers, not including maintenance, the electricity bill etc. If you can make software even 50% faster by increasing development time,…
> Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C.
I think this is what is most flawed in the paper. For (some) concurrent problems Go is about as fast as C [1].
But then again, I don't know what kind of computing requirements they have. Is there a reason why GRP computing isn't mentioned? They are really efficient and CUDA isn't that hard to learn.
> Rust allows the user to avoid common mistakes such as the access to invalid memory regions and race conditions
They seem to care about safety.
[1] https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
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
Earlier quoted context omitted.
> * Almost as fast as C That's the key point. Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C. A grad student (if paid properly) costs maybe 60k €/year. In comparison, we regularly spend more than 250k on new and faster computers, not including maintenance, the electricity bill etc. If you can make software even 50% faster by increasing development time,…
I'd agree but > Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C. I think this is what is most flawed in the paper. For (some) concurrent problems Go is about as fast as C [1]. But then again, I don't know what kind of computing requirements they have. Is there a reason why GRP computing isn't mentioned? They are really efficient and CUDA isn't that hard t…
Certainly, this was really only taken as a ballpark estimate of the performance difference. Looking at your link, it seems to have been slightly overestimating the difference, though the general point still stands: C is (in most cases) faster and there is (nearly) no case in which Go beats C.
> Is there a reason why GRP computing isn't mentioned?
> They are really efficient and CUDA isn't that hard to learn.
Sorry, not sure if you mean GPU instead of GRP in the first sentence. CUDA helps to some degree, but not always, e.g. when you are memory bandwidth bound (common in tensor networks in physics). I have no experience with Monte Carlo methods and can’t comment on whether they substantially benefit from CUDA; I know of at least one (Quantum Monte Carlo) code which runs much faster on a standard Xeon than on the Xeon Phi, though.
> They seem to care about safety.
Yes of course safety is nice to have and I’ll gladly learn Rust when I have some free time to get that safety at hopefully zero cost. But sacrificing performance is simply not competitive, if you can throw someone with gdb at the problem and get essentially the same "safety".
Earlier quoted context omitted.
Because they want the correct results?
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.