Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++'s `noexcept` can sometimes help or hurt performance

16bpp.net

Post reply on HN
Print view View original

121–130 of 166 posts

Re: C++'s `noexcept` can sometimes help or hurt performance

#121

Post by account42 »

bregma wrote: post #103
mcdeltat wrote: post #86

Earlier quoted context omitted.

> there is a guarantee here that noexcept functions don't throw. std::terminate has to be called. That has to be implemented Could you elaborate on how this causes more overhead than without noexcept? The fact that something has to be done when throwing an exception is true in both cases, right?. Naively it'd seem like without noexcept, you raise the exception; and with noexcept, you call std::terminate instead. Pres…

If you're on one of the platforms with sane exception handling, it's a matter of emitting different assembly code for the landing pad so that when unwinding it calls std::terminate instead of running destructors for the local scope. Zero additional overhead. If you're on old 32-bit Microsoft Windows using MSVC 6 or something, well, you might have problems. One of the lesser ones being increased overhead for noexcept.

> Zero additional overhead.

It's zero runtime overhead in the good case but still has an executable size overhead for functions that previously did not need to run any destructors.

Re: C++'s `noexcept` can sometimes help or hurt performance

#122

Post by forrestthewoods »

gumby wrote: post #119
forrestthewoods wrote: post #68

Earlier quoted context omitted.

No, there are just 3 relevant standard implementations. There are numerous independent libraries that perform very similar but non-conformant functionality. My complaint is that the C++ standards committee should, when possible, release code and not a specification. They shouldn't release a std::map spec that 3 different vendors implement. The committee should write and release a single std::map implementation. It's…

> Rust's standard library is not a spec, it's just code. I consider this profound weakness, not a strength. Don’t get me wrong: I recognize the benefits in the short term! But really long lived languages like FORTRAN, Lisp, C++ have benefited hugely from a spec-based standards approach adopted from other engineering practice. They have also benefited from cross-fertilization from different implementations which influ…

We may just have to disagree on this one.

The fact that some things benefit from a spec does not mean that all do things do. Almost everything defined by the C++ committee since 2014 is awful. The specs, once published, are unable to evolve due to ABI.

The Rust standard library is soooooooo much better than C++’s. By leaps and bounds. And it continues to improve with time. C++ is far worse and far more stagnant. That’s lose/lose!

I don’t see how you could possibly claim that std::map and std::deque being a spec is a profound strength.

The fact that you celebrate non-spec implementations such as Abseil and Folly seem to me to be evidence supporting implementations over specs!

To be clear I’m talking about the standard library, not the core language syntax.

Re: C++'s `noexcept` can sometimes help or hurt performance

#123

Post by leni536 »

Arech wrote: post #97
leni536 wrote: post #91

Earlier quoted context omitted.

Yes, qsort and bsearch can throw.

jfc... Can you give more info how did you learn this and to which lib implementation this applies?

https://eel.is/c++draft/alg.c.library#4

Any library implementation that is C++ compliant must implement this. I'm pretty sure that libstdc++ + glibc is compliant, assuming sane glibc compiler options.

Re: C++'s `noexcept` can sometimes help or hurt performance

#124

Post by leni536 »

tsimionescu wrote: post #100
Arech wrote: post #97

Earlier quoted context omitted.

jfc... Can you give more info how did you learn this and to which lib implementation this applies?

Well, given that qsort and bsearch take a function pointer and call it, that function pointer can easily point to a function that throws. So I think this applies to all implementations of qsort and bsearch. Especially since there is no way to mark a function pointer as noexcept.

> Especially since there is no way to mark a function pointer as noexcept.

There is, noexcept is part of the type since C++17. In fact, I prefer noexcept function pointer parameters for C library wrappers, as I don't expect most libraries written in C to deal with stack unwinding at all.

Re: C++'s `noexcept` can sometimes help or hurt performance

#125

Post by Arech »

gpderetta wrote: post #93
Arech wrote: post #79

Earlier quoted context omitted.

Eeeermm... I haven't heard an explosion, but 4+ hours has passed. Are you alive there, dude? Jokes aside - I'm always happy to be corrected, so please go on if I made a mistake somewhere.

You very likely can't always answer the question "will this function throw?", but it should be relatively easy to identify the subset of function that recursively call functions that are guaranteed not to throw. That's only a subset of all non-throwing functions of course.

Yes, my mistake was in confusion a run-time question "will it throw?" with "can it throw in theory?". The latter if I'm not mistaken again only requires a throw statement somewhere in a non-dead code, which is totally possible to find out for a code compiler could see.

Re: C++'s `noexcept` can sometimes help or hurt performance

#126

Post by [deleted] »

gumby wrote: post #119
forrestthewoods wrote: post #68

Earlier quoted context omitted.

No, there are just 3 relevant standard implementations. There are numerous independent libraries that perform very similar but non-conformant functionality. My complaint is that the C++ standards committee should, when possible, release code and not a specification. They shouldn't release a std::map spec that 3 different vendors implement. The committee should write and release a single std::map implementation. It's…

> Rust's standard library is not a spec, it's just code. I consider this profound weakness, not a strength. Don’t get me wrong: I recognize the benefits in the short term! But really long lived languages like FORTRAN, Lisp, C++ have benefited hugely from a spec-based standards approach adopted from other engineering practice. They have also benefited from cross-fertilization from different implementations which influ…

[deleted]

Re: C++'s `noexcept` can sometimes help or hurt performance

#127

Post by Arech »

terrymah wrote: post #107
Arech wrote: post #79

Earlier quoted context omitted.

Eeeermm... I haven't heard an explosion, but 4+ hours has passed. Are you alive there, dude? Jokes aside - I'm always happy to be corrected, so please go on if I made a mistake somewhere.

Determining if a function throws is a pretty basic bit of information collected in bottom up codegen (or during pre pass of a whole program optimization) and in no sense NP hard. Compilers have been doing it for decades and it’s useful Noexcept on the surface is useful, except for the terminate guarantee, which requires a ton of work to avoid metadata size growth and hurts inlining. If violations of noexcept were UB…

Yes, true, thanks. I confused "will it throw given inputs&state?" with "can it potentially throw?".

I wonder, why compilers don't expose that information? Some operator returning tri-state "this code provably doesn't throw | could throw | can't see, break the compilation" could help writing generic code immensely. Instead we have to resolve to multi-storey noexcept() operator inside a noexcept qualifier which is very detrimental for the code readability...

Re: C++'s `noexcept` can sometimes help or hurt performance

#128

Post by slaymaker1907 »

quotemstr wrote: post #28
TillE wrote: post #2

> I didn't know std::uniform_int_distribution doesn't actually produce the same results on different compilers I think this is genuinely my biggest complaint about the C++ standard library. There are countless scenarios where you want deterministic random numbers (for testing if nothing else), so std's distributions are unusable. Fortunately you can just plug in Boost's implementation.

> I think this is genuinely my biggest complaint about the C++ standard library What do you think of Abseil hash tables randomizing themselves (piggybacking on ASLR) on each start of your program?

Their justification is here https://github.com/abseil/abseil-cpp/issues/720

However, I personally disagree with them since I think it's really important to have _some_ basic reproducibility for things like reproducing the results of a randomized test. In that case, I'm going to avoid changing as much as possible anyways.

Re: C++'s `noexcept` can sometimes help or hurt performance

#129

Post by Arech »

terrymah wrote: post #107
Arech wrote: post #79

Earlier quoted context omitted.

Eeeermm... I haven't heard an explosion, but 4+ hours has passed. Are you alive there, dude? Jokes aside - I'm always happy to be corrected, so please go on if I made a mistake somewhere.

Determining if a function throws is a pretty basic bit of information collected in bottom up codegen (or during pre pass of a whole program optimization) and in no sense NP hard. Compilers have been doing it for decades and it’s useful Noexcept on the surface is useful, except for the terminate guarantee, which requires a ton of work to avoid metadata size growth and hurts inlining. If violations of noexcept were UB…

Interestingly, AUTOSAR C++14 Guidance (https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSA...) had a "Rule A15-4-4 (required, implementation, automated) A declaration of non-throwing function shall contain noexcept specification." which was thankfully removed in MISRA C++2023 (the latest guidance for C++17, can't give a link, it's a paid document), - it mandates it only for a few special functions (destructors, move constructors/assignments and a few more).

Re: C++'s `noexcept` can sometimes help or hurt performance

#130

Post by Arech »

leni536 wrote: post #123
Arech wrote: post #97

Earlier quoted context omitted.

jfc... Can you give more info how did you learn this and to which lib implementation this applies?

https://eel.is/c++draft/alg.c.library#4 Any library implementation that is C++ compliant must implement this. I'm pretty sure that libstdc++ + glibc is compliant, assuming sane glibc compiler options.

a perfect answer, thank you!
Post reply on HN