10 ms·

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

henrydark 5y ago
As per the piece, open 128 documents on a 128 core machine, and you'll see the difference.
- netr0ute 5y ago
  How many people actually use a 128 core machine though? The absolute biggest AMD Threadripper you can get only has 64.
  - tneumann 5y ago
    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.
  - henrydark 5y ago
    96 virtual cores is a popular choice on AWS, being cost effective in some industry scenarios. I'm certain the analysis of the piece applies
  - mcguire 5y ago
    No one needs more than 64 cores?
  - nybble41 5y ago
    > The absolute biggest AMD Threadripper you can get only has 64. You can get a machine with dual 64-core AMD EPYC 7662 CPUs[0] for a total of 128 cores. It will cost you almost $20k, though—for the most basic configuration. [0] https://bizon-tech.com/bizon-x6000.html#959:8714;960:4858;961:4985;962:4879;963:4882;968:4911;973:4993;979:4995;1076:5882 https://bizon-tech.com/bizon-x6000.html#959:8714;960:4858;96...
  - jrockway 5y ago
    Those Threadrippers have two vCPUs per core, so you can definitely have 128 things that appear to proceed in parallel.
  - kllrnohj 5y ago
    That seems like an awfully short sighted argument. Less than 20 years ago we were all using single-core CPUs. Now most of us have at least 6 cores if not more in a battery powered handheld device that we don't even expect to do much compute work on (aka, smartphones). And 8-16 cores w/ SMT are not an unusual consumer laptop/desktop configuration. The articles suggestion that it's only a matter of time for 128+ core CPUs to be common, at least in the server space, is probably the least contentious argument it makes?
    - netr0ute 5y ago
      128 cores is only 2x 64 cores, and 64 cores is a whopping 4x what AMD's top dog desktop CPU offers, so if you have to go this far for exceptions to be slow, then maybe they don't matter for most users.
      - kllrnohj 5y ago
        Your math is a bit off, confusing threads & cores. 128 threads is only 4x of what AMD's top desktop CPU offers, and is what current AMD server CPUs offer in a single socket system. And over the past 20 years consumer CPUs have 32x'd their thread count. A 4x increase over the next 10+ years really doesn't seem all that far-fetched. Also, the scaling problems show up far before 128 threads are used. The scaling issues start showing up at just 4-8 threads, depending on the error rate. Also also, C++ is used in a hell of a lot more places than just consumer desktops. So the current limitations of consumer desktops is fully irrelevant anyway.
mhh__ 5y ago
This is mostly my opinion too. My argument against exceptions is basically everything other than performance. To make a performance decision you have to build the code incrementally with feedback from how it is actually going to be used e.g. if almost every parse fails then you probably don't want to throw whereas if your code almost always succeeds you probably want your register back (i.e. use exceptions)
anarazel 5y ago
When I read the title, I was assuming it was going to be about worsened code generation when building with exception support. Not about, basically, throwing exceptions as fast as possible. That seems an odd concern given the current performance.
mlinksva 5y ago
Thanks a lot for your perf work on LibreOffice, which https://gerrit.libreoffice.org/q/Grandin https://gerrit.libreoffice.org/q/Grandin seems to confirm!
addaon 5y ago
I wouldn't necessarily expect to see throwing show up on a statistical profile. I would expect to see (and very much have seen) throwing showing up as a huge latency spike, leading to user-visible non-responsiveness. Especially in a cold situation (first throw after launch, or throwing after pages have been ejected), a surprising number of memory pages need to be populated to throw an exception.
tneumann 5y ago
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 http://wg21.link/p0709 It lists quite a few applications that explicitly forbid exceptions due to performance concerns.
- jcelerier 5y ago
  > I am the the original author, and trust me, I am describing a real world problem. for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system resource limit exhausted.. things like that). As much as massive parallel data processing tasks matter, I'd really prefer my language to not side-step writing end-user apps for something that happens at $bigcompany or $bigresearchlab. here's the list of binaries that link against libstdc++.so.6 in my /usr/bin: https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 - don't forget those please :)
  - mcguire 5y ago
    Are you arguing that C++ is unsuitable for massive parallel data processing tasks?
    - garbagecoder 5y ago
      No, he's arguing that he'd prefer it not be if that means breaking support for end user apps which is what the OP is arguing for.
brundolf 5y ago
It probably depends a whole lot on whether exceptions are used only for exceptions, or for control-flow. The author seemed to be treating this question fairly pessimistically
downut 5y ago
In 30 years of c++ I've never seen error checking + throw in a tight numeric intensive loop like this. Sure, somebody could do it. I'd have a chat with a coworker who wrote something like that. I only use exceptions for cleanly unwinding the stack when an unrecoverable error occurs. I design and implement my code so that is rare.
- olvy0 5y ago
  Totally agree, I do the same, up to and including having a chat with a coworker who wrote code like that. I just did that last week, in fact. Code that uses exceptions like this is a code smell, especially when performance is important. Using exceptions as control flow instead of if/loops is not a good design, IMO. Note that this is in C++. I consider this style of writing not idiomatic, despite the STL doing it. I use either error return codes or std::optional (itself having a set of problems but IMO better than exceptions). I'm more willing to accept this kind of code in Java, where it's more or less idiomatic. Less so in C#, where the tendency in the last 15 years has been to use the Try__ method instead of throwing exceptions.
nicoburns 5y ago
I feel like the main problem with exceptions isn't the performance, it's the non-local control flow and the fact that it makes enumerating all possible failure modes almost impossible. IMO the only way that exceptions could be justified (other than being the status quo) is if they were much faster than Result/Maybe types. Performance parity doesn't make them worthwhile!
CJefferson 5y ago
Counter-conterpoint: I've worked on two applications C++ which we had to "de-exception", as exception handling was taking >25% of the time when we profiled. You could argue we were using "too many exceptions", but to me it's the obvious way to unwind in C++.. except it's not fast enough, so we had to switch to a proto-Rust (this was before Rust) style system.
passivate 5y ago
Do you still have any notes from your profiling?
- grandinj 5y ago
  I gave talks at the Libreoffice conference in 2019 https://www.youtube.com/watch?v=QnBIeeBZf70 https://www.youtube.com/watch?v=QnBIeeBZf70 and in 2021 https://www.youtube.com/watch?v=VbL6mXXnFdo&list=PL0pdzjvYW9RFSMB71bqh_bT-SkX5FOS9x&index=8 https://www.youtube.com/watch?v=VbL6mXXnFdo&list=PL0pdzjvYW9...

henrydark 5y ago

As per the piece, open 128 documents on a 128 core machine, and you'll see the difference.

netr0ute 5y ago
How many people actually use a 128 core machine though? The absolute biggest AMD Threadripper you can get only has 64.
- tneumann 5y ago
  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.
- henrydark 5y ago
  96 virtual cores is a popular choice on AWS, being cost effective in some industry scenarios. I'm certain the analysis of the piece applies
- mcguire 5y ago
  No one needs more than 64 cores?
- nybble41 5y ago
  > The absolute biggest AMD Threadripper you can get only has 64. You can get a machine with dual 64-core AMD EPYC 7662 CPUs[0] for a total of 128 cores. It will cost you almost $20k, though—for the most basic configuration. [0] https://bizon-tech.com/bizon-x6000.html#959:8714;960:4858;961:4985;962:4879;963:4882;968:4911;973:4993;979:4995;1076:5882 https://bizon-tech.com/bizon-x6000.html#959:8714;960:4858;96...
- jrockway 5y ago
  Those Threadrippers have two vCPUs per core, so you can definitely have 128 things that appear to proceed in parallel.
- kllrnohj 5y ago
  That seems like an awfully short sighted argument. Less than 20 years ago we were all using single-core CPUs. Now most of us have at least 6 cores if not more in a battery powered handheld device that we don't even expect to do much compute work on (aka, smartphones). And 8-16 cores w/ SMT are not an unusual consumer laptop/desktop configuration. The articles suggestion that it's only a matter of time for 128+ core CPUs to be common, at least in the server space, is probably the least contentious argument it makes?
  - netr0ute 5y ago
    128 cores is only 2x 64 cores, and 64 cores is a whopping 4x what AMD's top dog desktop CPU offers, so if you have to go this far for exceptions to be slow, then maybe they don't matter for most users.
    - kllrnohj 5y ago
      Your math is a bit off, confusing threads & cores. 128 threads is only 4x of what AMD's top desktop CPU offers, and is what current AMD server CPUs offer in a single socket system. And over the past 20 years consumer CPUs have 32x'd their thread count. A 4x increase over the next 10+ years really doesn't seem all that far-fetched. Also, the scaling problems show up far before 128 threads are used. The scaling issues start showing up at just 4-8 threads, depending on the error rate. Also also, C++ is used in a hell of a lot more places than just consumer desktops. So the current limitations of consumer desktops is fully irrelevant anyway.

mhh__ 5y ago

This is mostly my opinion too. My argument against exceptions is basically everything other than performance. To make a performance decision you have to build the code incrementally with feedback from how it is actually going to be used e.g. if almost every parse fails then you probably don't want to throw whereas if your code almost always succeeds you probably want your register back (i.e. use exceptions)

anarazel 5y ago

When I read the title, I was assuming it was going to be about worsened code generation when building with exception support. Not about, basically, throwing exceptions as fast as possible. That seems an odd concern given the current performance.

mlinksva 5y ago

Thanks a lot for your perf work on LibreOffice, which https://gerrit.libreoffice.org/q/Grandin https://gerrit.libreoffice.org/q/Grandin seems to confirm!

addaon 5y ago

I wouldn't necessarily expect to see throwing show up on a statistical profile. I would expect to see (and very much have seen) throwing showing up as a huge latency spike, leading to user-visible non-responsiveness. Especially in a cold situation (first throw after launch, or throwing after pages have been ejected), a surprising number of memory pages need to be populated to throw an exception.

tneumann 5y ago

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 http://wg21.link/p0709 It lists quite a few applications that explicitly forbid exceptions due to performance concerns.

jcelerier 5y ago
> I am the the original author, and trust me, I am describing a real world problem. for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system resource limit exhausted.. things like that). As much as massive parallel data processing tasks matter, I'd really prefer my language to not side-step writing end-user apps for something that happens at $bigcompany or $bigresearchlab. here's the list of binaries that link against libstdc++.so.6 in my /usr/bin: https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 https://paste.ofcode.org/gfZJwx4puVx7Uxy9a7BBU3 - don't forget those please :)
- mcguire 5y ago
  Are you arguing that C++ is unsuitable for massive parallel data processing tasks?
  - garbagecoder 5y ago
    No, he's arguing that he'd prefer it not be if that means breaking support for end user apps which is what the OP is arguing for.

brundolf 5y ago

It probably depends a whole lot on whether exceptions are used only for exceptions, or for control-flow. The author seemed to be treating this question fairly pessimistically

downut 5y ago

In 30 years of c++ I've never seen error checking + throw in a tight numeric intensive loop like this. Sure, somebody could do it. I'd have a chat with a coworker who wrote something like that. I only use exceptions for cleanly unwinding the stack when an unrecoverable error occurs. I design and implement my code so that is rare.

olvy0 5y ago
Totally agree, I do the same, up to and including having a chat with a coworker who wrote code like that. I just did that last week, in fact. Code that uses exceptions like this is a code smell, especially when performance is important. Using exceptions as control flow instead of if/loops is not a good design, IMO. Note that this is in C++. I consider this style of writing not idiomatic, despite the STL doing it. I use either error return codes or std::optional (itself having a set of problems but IMO better than exceptions). I'm more willing to accept this kind of code in Java, where it's more or less idiomatic. Less so in C#, where the tendency in the last 15 years has been to use the Try__ method instead of throwing exceptions.

nicoburns 5y ago

I feel like the main problem with exceptions isn't the performance, it's the non-local control flow and the fact that it makes enumerating all possible failure modes almost impossible. IMO the only way that exceptions could be justified (other than being the status quo) is if they were much faster than Result/Maybe types. Performance parity doesn't make them worthwhile!

CJefferson 5y ago

Counter-conterpoint: I've worked on two applications C++ which we had to "de-exception", as exception handling was taking >25% of the time when we profiled. You could argue we were using "too many exceptions", but to me it's the obvious way to unwind in C++.. except it's not fast enough, so we had to switch to a proto-Rust (this was before Rust) style system.

passivate 5y ago

Do you still have any notes from your profiling?

grandinj 5y ago
I gave talks at the Libreoffice conference in 2019 https://www.youtube.com/watch?v=QnBIeeBZf70 https://www.youtube.com/watch?v=QnBIeeBZf70 and in 2021 https://www.youtube.com/watch?v=VbL6mXXnFdo&list=PL0pdzjvYW9RFSMB71bqh_bT-SkX5FOS9x&index=8 https://www.youtube.com/watch?v=VbL6mXXnFdo&list=PL0pdzjvYW9...