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

131–140 of 166 posts

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

#131

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.

but to me these are - again - a user induced problems. I'm interested if a user doesn't do stupid things, should they still afraid that a standard extern C code could throw? Say, std::sprintf() which if I'm not mistaken boils down to C directly? Are there cases where C std lib could throw without a "help from a user"?

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

#132

Post by Arech »

muth02446 wrote: post #117

RE: unexpected performance degradation programs can be quite sensitive to how code is laid out because of cache line alignment, cache conflicts etc. So random changes can have a surprising impact. There was a paper a couple of years ago explaining this and how to measure compiler optimizations more reliably. Sadly, I do not recall the title/author.

It would be super interesting to read the paper. Please post a link or some more details if you will remember them.

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

#133

Post by kazinator »

forrestthewoods wrote: post #122
gumby wrote: post #119

Earlier quoted context omitted.

> 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…

Computer programs that other computer programs use all require a detailed functional spec.

Entertainment software, not so much.

In between, you need varying amounts of spec.

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

#134

Post by bregma »

account42 wrote: post #121
bregma wrote: post #103

Earlier quoted context omitted.

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.

Very true. Then again, if you don't need to tear down anything (ie. run destructors) during error handling you're either not doing any error handling or you're not doing any useful work.

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

#135

Post by leni536 »

Arech wrote: post #131
leni536 wrote: post #123

Earlier quoted context omitted.

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.

but to me these are - again - a user induced problems. I'm interested if a user doesn't do stupid things, should they still afraid that a standard extern C code could throw? Say, std::sprintf() which if I'm not mistaken boils down to C directly? Are there cases where C std lib could throw without a "help from a user"?

https://eel.is/c++draft/res.on.exception.handling#2

I general functions from the C standard library must not throw, except for the ones taking function pointers that they execute.

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

#136

Post by forrestthewoods »

kazinator wrote: post #133
forrestthewoods wrote: post #122

Earlier quoted context omitted.

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…

Computer programs that other computer programs use all require a detailed functional spec. Entertainment software, not so much. In between, you need varying amounts of spec.

> Computer programs that other computer programs use all require a detailed functional spec.

And yet most programs that are used by other programs do not provide a detailed functional spec! How curious.

Most computer programs do not a formal, detailed, functional spec. They simply are what they are. Furthermore, the type of specs we are talking about are incomplete and purposefully leave a lot of room open to implementers to make different choices. Their choices are unspecified but fully relied upon.

Hyrum's Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

std::deque has an underdefined spec such that the MSVC implementation meets the spec but is utterly worthless. And it can't be fixed because that would break the ABI.

In this thread I'm specifically talking about the C++ standard library specification and implementations. Whether other software benefits from a detailed spec or not is outside the scope of this conversation. I maintain that the C++ standards committee should provide a std::deque implementation and not a spec. Thus far no one has even attempted to argue why it's better as a spec. Womp womp.

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

#137

Post by terrymah »

account42 wrote: post #120
terrymah wrote: post #106

Earlier quoted context omitted.

I think WG21 has been violently against adding additional UB to the language, because of some hacker news articles a decade ago about people being alarmed at null pointer checks being elided or things happening that didn’t match their expectation in signed int overflow or whatever. Generally it seems a view of spread that compiler implementers view undefined behavior as a license to party, that we’re generally having…

Could the UB version of noexcept be provided as a compiler extension? Either a separate attribute or a compiler flag to switch the behavior would be fine.

We had a UB version of noexcept for a very, very long time. __declspec(nothrow), the throw() function specifier, etc.

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

#138

Post by terrymah »

aw1621107 wrote: post #116
terrymah wrote: post #106

Earlier quoted context omitted.

I think WG21 has been violently against adding additional UB to the language, because of some hacker news articles a decade ago about people being alarmed at null pointer checks being elided or things happening that didn’t match their expectation in signed int overflow or whatever. Generally it seems a view of spread that compiler implementers view undefined behavior as a license to party, that we’re generally having…

> I think WG21 has been violently against adding additional UB to the language, because of some hacker news articles a decade ago about people being alarmed at null pointer checks being elided or things happening that didn’t match their expectation in signed int overflow or whatever. Huh, didn't expect the no-UB sentiment to have extended that far back! > Regarding “not pan out”: I think the overhead of noexcept for…

Things are much better in 2024 in MSVC than they were in 2014. The overhead today is mostly the additional metadata associated with tracking the state, and most of the inline compatibilities were worked through (with a ton of work by the compiler devs). So it's a binary size issue. We've even been working on that (I remember doing work to combine adjacent identical regions, etc). Not sure what the status is in GCC/LLVM today.

I'm just a little sore about it because it was being sold as a "hey here is an optimization!" and it very much was not, at least from where I was sitting. I thought this was a very very good case of having it be UB (I think the entire class of user source annotations like this should be UB if the runtime behavior violates the user annotation)

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

#139

Post by SleepyMyroslav »

gumby wrote: post #118
SleepyMyroslav wrote: post #74

Earlier quoted context omitted.

>In the end the only sane thing to do if you want any reproducibility across operating systems is to exclusively use ... no std library code in portable code. FTFY. Ofc there are no absolutes. In gamedev essential type info bits and intrinsics are either allowed back or wrapped. Algorithm library is another bit allowed for the most part ( no unstable sort and such ). I know your approach of 'one ring-libc++ to rule t…

> no std library code in portable code. FTFY. Just want to clarify what I think you meant: no std library code in portable binaries , something I agree with 100%. If you distribute in source, I believe almost always the opposite is true: relying on the standard library is probably a win. Not every time: some complex code bases have nonstandard requirements or can benefit from nonstandard code. Gaming is a good exampl…

I am not sure I understand. You declare a win with no explanations or reasons.

What is so beneficial in having different implementation of same functionality? Why source being available makes difference?

We can ignore cases of optimized per platform implementations because std was not made for that. None of platforms that make sense to support now were available back when current ABI was set in stone.

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

#140

Post by lmz »

pjmlp wrote: post #82
Maxatar wrote: post #40

Earlier quoted context omitted.

Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. Clang is compatible with GCC's standard library/libstdc++ and MSVC's standard library because the clang compiler explicitly supports them, but it's not possible to use clang's standard library with GCC in a standard conforming way or interchange GCC's with MSVC's standard library. There are some hacks that let you use…

As proven by musl versus glibc issues, that possibility is mostly theoric, with plenty of gotchas in practice.

Which musl issues are to do with GCC? Alternate C libraries are common on Linux e.g. uclibc, dietlibc, bionic... Not to mention also the other OSs GCC runs on that don't use glibc. Of course, mixing C libraries between the main executable and libraries probably won't work.
Post reply on HN