3 ms·

Exceptions being contrary to zero-overhead is not something that is just my opinion. Here's Herb Sutter's detailed white paper on the topic: http://www.open-st

Exceptions being contrary to zero-overhead is not something that is just my opinion. Here's Herb Sutter's detailed white paper on the topic: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070... ETA: an uncontended mutex lock takes around 10-30ns depending on the machine. Any kind of exception is far more costly.

qeqeqeqe 7y ago
Bjarne Stroustrup wrote a rebuttal to that proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p194...
- thedance 7y ago
  Stroustrup constructs a bit of a false dichotomy there. He presents the choice between exceptions and explicit error propagation and checking, but there is a third way. If the allocator is simply infallible and std::bad_alloc just doesn't exist, and the program terminates on allocation failure instead, then you need neither exceptions nor error codes. Since std::bad_alloc is such a prominent root cause of all exceptions, and since it's preposterous to believe a program can continue after the global allocator stops working, this turns out to be a dramatic simplification of the overall program. Once you get rid of allocator exceptions it's not a big mental leap to just decide to get rid of all of them.
  - jfkebwjsbx 7y ago
    bad_alloc does not mean the allocator has stopped working. It only means that a particular allocation cannot be served. And there are plenty of other root causes for exceptions in real programs, not just allocations. That does not mean one needs exceptions, though.
  - usrnm 7y ago
    But std::bad_alloc does exist and it's possible and sometimes necessary to write correct software that's able to handle allocation errors. What we probably need is some sort of a compiler switch, but it will significantly complicate writing generic multi-purpose libraries
    - thedance 7y ago
      bad_alloc doesn't just naturally spring into being. If you override operator new, your implementation may not use it (for example tcmalloc does not throw if it can't allocate, it logs a message and terminates the program). Many systems of the type you mention, embedded control systems and the like where correctness actually matters, don't use new and delete anyway. They often use placement new with space statically allocated at program startup. These are the same kinds of projects that often decide to not use exceptions.
  - ncmncm 7y ago
    When the global allocator fails, you might not be able to do much... except set a flag, and free a big block of memory that was reserved against just such an event. Then the program can do whatever cleanup is warranted, maybe freeing up a variety of other resources, and then maybe re-reserve that block, and forge ahead. But when you actually care about performance, you often are not using the global allocator. A local allocation failure is nothing to panic over. Generally, only the higher level code -- where the handler is -- knows, or needs to care, what kind of allocator failed. The low-level code gets to just bail out, as it should.
    - hoseja 7y ago
      You could also have just tried to allocate 42 terabytes of memory and have a well defined strategy for what to do in case this fails...
      - daemin 7y ago
        Yeah, but in that case you would use your own allocator fit for this purpose and not just new or malloc.
ncmncm 7y ago
Contended mutex locks, of course, may take far, far longer than 30ns, and 30 nanoseconds is an eternity, enough time to run 500 instructions on a modern CPU. Herb Sutter is, reliably, always right on his facts, but always mistaken on his opinions.
quietbritishjim 7y ago
> an uncontended mutex lock takes around 10-30ns depending on the machine. I am grateful for this. But I do wish the article had a few more comparisons like this, up to and including things much more expensive than exceptions, so readers could make their own decisions rather than just read about how terrible exceptions are. As another data point, I just read that a Linux system call that does no actual work takes about 250ns, so about a fifth of the time for an exception from the article. Of course that's a totally unknown machine that could be much slower or faster than the one used for the article's benchmark. But I still found it interesting that they're the same order of magnitude – I hadn't expected exceptions to be quite that slow.
- je42 7y ago
  Herb Sutter also has presentation on this: https://www.youtube.com/watch?v=ARYP83yNAWk https://www.youtube.com/watch?v=ARYP83yNAWk

qeqeqeqe 7y ago

Bjarne Stroustrup wrote a rebuttal to that proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p194...

thedance 7y ago
Stroustrup constructs a bit of a false dichotomy there. He presents the choice between exceptions and explicit error propagation and checking, but there is a third way. If the allocator is simply infallible and std::bad_alloc just doesn't exist, and the program terminates on allocation failure instead, then you need neither exceptions nor error codes. Since std::bad_alloc is such a prominent root cause of all exceptions, and since it's preposterous to believe a program can continue after the global allocator stops working, this turns out to be a dramatic simplification of the overall program. Once you get rid of allocator exceptions it's not a big mental leap to just decide to get rid of all of them.
- jfkebwjsbx 7y ago
  bad_alloc does not mean the allocator has stopped working. It only means that a particular allocation cannot be served. And there are plenty of other root causes for exceptions in real programs, not just allocations. That does not mean one needs exceptions, though.
- usrnm 7y ago
  But std::bad_alloc does exist and it's possible and sometimes necessary to write correct software that's able to handle allocation errors. What we probably need is some sort of a compiler switch, but it will significantly complicate writing generic multi-purpose libraries
  - thedance 7y ago
    bad_alloc doesn't just naturally spring into being. If you override operator new, your implementation may not use it (for example tcmalloc does not throw if it can't allocate, it logs a message and terminates the program). Many systems of the type you mention, embedded control systems and the like where correctness actually matters, don't use new and delete anyway. They often use placement new with space statically allocated at program startup. These are the same kinds of projects that often decide to not use exceptions.
- ncmncm 7y ago
  When the global allocator fails, you might not be able to do much... except set a flag, and free a big block of memory that was reserved against just such an event. Then the program can do whatever cleanup is warranted, maybe freeing up a variety of other resources, and then maybe re-reserve that block, and forge ahead. But when you actually care about performance, you often are not using the global allocator. A local allocation failure is nothing to panic over. Generally, only the higher level code -- where the handler is -- knows, or needs to care, what kind of allocator failed. The low-level code gets to just bail out, as it should.
  - hoseja 7y ago
    You could also have just tried to allocate 42 terabytes of memory and have a well defined strategy for what to do in case this fails...
    - daemin 7y ago
      Yeah, but in that case you would use your own allocator fit for this purpose and not just new or malloc.

ncmncm 7y ago

Contended mutex locks, of course, may take far, far longer than 30ns, and 30 nanoseconds is an eternity, enough time to run 500 instructions on a modern CPU. Herb Sutter is, reliably, always right on his facts, but always mistaken on his opinions.

quietbritishjim 7y ago

> an uncontended mutex lock takes around 10-30ns depending on the machine. I am grateful for this. But I do wish the article had a few more comparisons like this, up to and including things much more expensive than exceptions, so readers could make their own decisions rather than just read about how terrible exceptions are. As another data point, I just read that a Linux system call that does no actual work takes about 250ns, so about a fifth of the time for an exception from the article. Of course that's a totally unknown machine that could be much slower or faster than the one used for the article's benchmark. But I still found it interesting that they're the same order of magnitude – I hadn't expected exceptions to be quite that slow.

je42 7y ago
Herb Sutter also has presentation on this: https://www.youtube.com/watch?v=ARYP83yNAWk https://www.youtube.com/watch?v=ARYP83yNAWk