2 ms·

> %1 difference in tight loops I'd love to see how you can reach this number. I hear a lot of people complaining about supposedly degraded performances due to

by shakow 3y ago

> %1 difference in tight loops I'd love to see how you can reach this number. I hear a lot of people complaining about supposedly degraded performances due to bound checking; but IME, even on number crunching HPC code, I have never been able to get a signal greater than noise regarding bound checks, which can be explained by: (i) the prediction pipeline doing its job, (ii) iterators eliding bound-checks at compile time, (iii) bound checking being dwarfed by the actual computations within the tight loop. Remember to measure what you optimize for first before going on an intuition.

bayindirh 3y ago
Disclaimer: I'm an HPC admin and both develop code on these things and manage them. The code I have written was doing ~1.7M iterations per core, per second when I implemented it w/o bounds checking and locks. It was designed to be fast from the start, so I never tried bounds checking. I'm restarting the work on the code soon-ish, so I'll be writing a benchmark module for the thing. If you can provide me an e-mail address, I'll implement both, do the tests, and provide you the results, and we can discuss on it, too. Also, I'll see whether GCC-14 (or whatever comes next) is intelligent enough to eliminate bounds checks in these cases. The following part of the code [0], was running with much higher iteration numbers inside the "tight loop", but I never benchmarked it, because its iteration count is both inconsistent (due to adaptive nature), and was meaningless in the bigger picture (where 1.7M/sec/core number comes in). That code was never optimized before measurement, and the biggest bottleneck was memory controller at the end. I needed to reorder matrices to pass that hurdle, yet the Ph.D. was complete, and speed was adequate, so we didn't bother, TBH. [0]: https://journals.tubitak.gov.tr/elektrik/vol29/iss2/45/ https://journals.tubitak.gov.tr/elektrik/vol29/iss2/45/
- Robin_Message 3y ago
  It's worth noting that HPC is a different problem space from say, kernels, drivers, codecs, and browsers, in that HPC is not generally expecting to deal with adversairial input, and those other spaces are. So the safety-performance trade-off is truly different between you and many of the commentators who are rightly pointing out C/C++'s atrocious track record in the secure space. Also, I've done a small amount of scientific HPC, and as I see it "correct" is infinitely more important than "fast". If you look at the amount of incorrect scientific papers that trace back to accidentally and silently corrupted data, I think maybe it might sense to consider using any and all possible tools to avoid corruption, of which Rust is but one example (and you've named others like valgrind).
  - bayindirh 3y ago
    However, this doesn't mean that an HPC application has no need to verify its input, fail gracefully if something goes wrong, or have to be absolutely rock solid because it's running for days (or weeks in some cases) while being dead-on the results of the problem evaluated. You're right. Correct is the king in HPC, but it's a king which doesn't exile speed. What we do is to solve a couple of known cases correctly in MATLAB or something similar, then try to hit the same results first (or be better if we can do that), then make it iteratively faster without deviating it from a bit (Same result with 1e-32 precision, IOW). This "comparing with a known truth" process is a great indicator of calculation sanity. Other parts are iteratively tested with Valgrind and custom test suites, from function level to end to end, automatically after each build. End to end tests are very expensive in the Valgrind memory profiler (esp. if you're testing multi-thread code), so we do these weekly generally, but I think the idea is clear.

by shakow 3y ago

bayindirh 3y ago

Disclaimer: I'm an HPC admin and both develop code on these things and manage them. The code I have written was doing ~1.7M iterations per core, per second when I implemented it w/o bounds checking and locks. It was designed to be fast from the start, so I never tried bounds checking. I'm restarting the work on the code soon-ish, so I'll be writing a benchmark module for the thing. If you can provide me an e-mail address, I'll implement both, do the tests, and provide you the results, and we can discuss on it, too. Also, I'll see whether GCC-14 (or whatever comes next) is intelligent enough to eliminate bounds checks in these cases. The following part of the code [0], was running with much higher iteration numbers inside the "tight loop", but I never benchmarked it, because its iteration count is both inconsistent (due to adaptive nature), and was meaningless in the bigger picture (where 1.7M/sec/core number comes in). That code was never optimized before measurement, and the biggest bottleneck was memory controller at the end. I needed to reorder matrices to pass that hurdle, yet the Ph.D. was complete, and speed was adequate, so we didn't bother, TBH. [0]: https://journals.tubitak.gov.tr/elektrik/vol29/iss2/45/ https://journals.tubitak.gov.tr/elektrik/vol29/iss2/45/

Robin_Message 3y ago
It's worth noting that HPC is a different problem space from say, kernels, drivers, codecs, and browsers, in that HPC is not generally expecting to deal with adversairial input, and those other spaces are. So the safety-performance trade-off is truly different between you and many of the commentators who are rightly pointing out C/C++'s atrocious track record in the secure space. Also, I've done a small amount of scientific HPC, and as I see it "correct" is infinitely more important than "fast". If you look at the amount of incorrect scientific papers that trace back to accidentally and silently corrupted data, I think maybe it might sense to consider using any and all possible tools to avoid corruption, of which Rust is but one example (and you've named others like valgrind).
- bayindirh 3y ago
  However, this doesn't mean that an HPC application has no need to verify its input, fail gracefully if something goes wrong, or have to be absolutely rock solid because it's running for days (or weeks in some cases) while being dead-on the results of the problem evaluated. You're right. Correct is the king in HPC, but it's a king which doesn't exile speed. What we do is to solve a couple of known cases correctly in MATLAB or something similar, then try to hit the same results first (or be better if we can do that), then make it iteratively faster without deviating it from a bit (Same result with 1e-32 precision, IOW). This "comparing with a known truth" process is a great indicator of calculation sanity. Other parts are iteratively tested with Valgrind and custom test suites, from function level to end to end, automatically after each build. End to end tests are very expensive in the Valgrind memory profiler (esp. if you're testing multi-thread code), so we do these weekly generally, but I think the idea is clear.