Hacker News Reader

Comment by bayindirh | Hacker News Reader

Depends on what you're building. If the code you're running is not resource intensive and relatively short-running, developer time is more expensive.

However, if your program is long running and requires high performance (number crunching, simulations, HPC in general), %1 difference in tight loops affect your total runtime by hours, if not days. Then, user-time is much more expensive, hence you need more speed. Also, in this case you're maxing out ~100 servers in terms of power and TDP, so a shorter runtime has a bigger impact on your energy bill, and global warming.

If I can run more users' code for the same power and time budget, and conclude more research, developer time to be damned. They can spend as much as time they like.

Tech people tend to say developers are expensive and hardware is cheap. No it's not, if you're using it at its max capacity.

View on HN

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

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/

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

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.

Reply on news.ycombinator.com