51–60 of 115 posts
Earlier quoted context omitted.
This seems to have been fixed 3 hours ago: https://github.com/marblestation/benchmark-leapfrog/commit/c...
Yes, but m is zero anyway.
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?
I don't belive in this result! C slower than Rust in 11 times!!! Are they kidding?! http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... -- in this benchmarks C in most cases faster than Rust, but only in few they have the same performance.
Earlier quoted context omitted.
Yes: Safety does not get you correct results where non-safety would have given you wrong results. Safety gives you correct results in some cases where non-safety would have given you no result. Those cases are easy to identify and can be solved using standard debugging techniques. So safety gets you faster development: less debugging, easier parallelisation etc., but it does not give you correct results, nor does it…
You legitimately can not imagine a scenario where a program is written which could give a result that appears correct but isn't due to a bug? And you legitimately can't imagine how reducing the likelihood of making bugs by using a language+compiler which can identify/prevent more of them would help? I'll leave you to it then.
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++.
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…
At this point it is not the language expertise, but knowing about your tools.
Earlier quoted context omitted.
Why would one care about safety in a science context?
One wouldn't, generally, at least in the astrophysics domain. The kinds of guarantees Rust makes don't add anything.
Then again, Fortran would cover these scenarios and is better established.
Earlier quoted context omitted.
Why would one care about safety in a science context?
Because they want the correct results?
Fortran 2008 is already quite modern in language features and doesn't suffer from C safety issues.
EDIT: typo.
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 see how Go would be a better option than it.
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…
It appears that it doesn't run correctly (rust optimizes out the actual integration, and values are all set to NaN!)
https://github.com/marblestation/benchmark-leapfrog/issues/6
Earlier quoted context omitted.
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.