Hacker News Reader

tneumannon Current hardware trends make C++ exceptions harder to justify

A dual socket EPYC costs about 15K. You can rent some online for 400$ a month. This gives you 128 cores for a relatively low price.

tneumannon Current hardware trends make C++ exceptions harder to justify

The main problem is the unwinding lock. Memory allocation is a bit unfortunate, too, but much less so.

Note that I am trying to fix the unwinding problem, I have submitted a patch to libunwind to eliminate the contention during unwinding:

https://reviews.llvm.org/D120243

It require application support, unfortunately, as there is currently no way that libunwind can figure out if a shared library has been added or removed. But if you are willing to indicate that from within the application the performance problem is mostly fixed. The memory allocation issue remains, but I can live with that. I cannot live with single threaded unwinding.

tneumannon Current hardware trends make C++ exceptions harder to justify

Of course the fib example is extreme. But some code bases do a lot of calls, and people care about calling overhead. I think a moderate calling overhead like, e.g., with Herbecptions is acceptable, because usually people doing something useful in a function that will mask the calling overhead. But other approaches are really to expensive to justify, they violate the zero-overhead promise of C++.

tneumannon Current hardware trends make C++ exceptions harder to justify

That argument is only true in single threaded applications, at least given today's exception implementations. The more threads you have, the more problematic exceptions become. On the large machine you start to see performance problems with 0.1% failure rate, which is not that much. An core counts continue to rise.

tneumannon Current hardware trends make C++ exceptions harder to justify

I am the the original author, and trust me, I am describing a real world problem. I run massive parallel data processing tasks on machines with 128 cores, and unfortunately some of them produce errors deep within the processing pipeline. From a programming perspective exceptions would be ideal for that scenario, but they cause severe performance problems.

Just think about this: If you have a 100 cores, and 1% of your tasks fail, one core is constantly unwinding. And due to the global lock you quickly get a queue of single threaded unwinding tasks. And things become worse, we expect to have machine with 256 cores soon, and there it is even more dangerous to throw.

If you do not believe me look here: http://wg21.link/p0709 It lists quite a few applications that explicitly forbid exceptions due to performance concerns.