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

141–150 of 166 posts

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

#141

Post by pjmlp »

lmz wrote: post #140
pjmlp wrote: post #82

Earlier quoted context omitted.

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.

As there are common people on forums searching for problems with their C code crashing and burning, because while those libraries conform to ISO C standard, their implementation defined semantics aren't the same.

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

#142

Post by account42 »

Maxatar wrote: post #40
gumby wrote: post #33

Earlier quoted context omitted.

I consider the current tradeoff to be a feature. It permits implementations to take advantage of target-specific affordances (your thread case is an example) as well as taking different implementation strategies (e.g. the small string optimization is different in libc++ and libstdc++). Also you may use another, independent standard library because you prefer its implementation decisions. Meanwhile they remain compati…

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…

> but it's not possible to use clang's standard library with GCC

Of course it is. Both libc++ and GCC do make the effort to keep that compatibility going.

> in a standard conforming way

What is that supposed to mean here? GCC doesn't let you simply specify -stdlib=libc++ but while it's unfortunate it just means that you have to use -nostdlib++ and add the libc++ include and linking flags manually.

> There are some hacks that let you use some parts of libc++ with GCC by using the nostdlib flag, but this disables a lot of C++ functionality such as exception handling, RTTI, type traits. These features are in turn used by things like std::vector, std::map, etc... so you won't be able to use those classes either, and so on so forth...

-nostdlib++ is not a hack but the documented way for using a different standard library implementation. This doesn't prevent you from using exceptions and other runtime functionality.

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

#143

Post by account42 »

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.

musl and glibc are both compatible for the POSIX portion of the API they provide. GCC also has lots of GNU specific functions but so what?

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

#144

Post by account42 »

gumby wrote: post #60
Maxatar wrote: post #53

Earlier quoted context omitted.

None of those are implementations of the C++ standard library. None of them even live in the same namespace as the standard library so your claim that they remain compatible at the source level is nonsense. Just a simple Google search would reveal that you are wrong about this and what's worse is that you place the burden on me to have to disprove your wrong assertions as opposed to providing references that justify…

> Just a simple Google search would reveal that you are wrong about this and what's worse is that you place the burden on me to have to disprove your wrong assertions as opposed to providing references that justify your position: How rude. Have you used any of those libraries or perhaps relied on Google's "AI"-generated answer? > None of those are implementations of the C++ standard library. HPX, EASTL specifically a…

EASTL is not a C++ standard library implementation even if it's design does follow it in parts.

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

#145

Post by account42 »

forrestthewoods wrote: post #68
gumby wrote: post #51

Earlier quoted context omitted.

See my parallel reply: there are much more than just three, and all work with the three/four most dominant compilers these days as well as less dominant ones like EDG or Intel.

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…

C++'s approach also doesn't stop alternative approaches implemented in third-party libraries and sometimes those also do get added to the C++ standard library spec (many standard APIs are very close to pre-existing Boost APIs, for better or worse).

Since most standard library implementations are open source you CAN also pick components individually even if it takes a bit more effort to get all the required support cruft and avoid namespace clashes.

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

#146

Post by account42 »

tsimionescu wrote: post #94
compiler-guy wrote: post #6

Earlier quoted context omitted.

The compiler can tell about the immediate function, but not any functions it calls. If a function marked noexcept calls a function that throws an exception, then the program is terminated with an uncaught exception. A called function can throw through a non-noexcept function to a higher-level exception handler no problem. So in order to avoid changing the semantics of the function, the compiler would have to be able…

> A called function can throw through a non-noexcept function to a higher-level exception handler no problem. This is exactly the problem. To have made this a useful feature, it should have been more restrictive: a noexcept function should not have been allowed to call any function or operator or lambda that is not marked noexcept. Some extra syntax to allow function templates to be made "conditionally noexcept" woul…

That would have been too limiting since there are many (e.g. C) functions that can never throw but are not marked noexcept. Not being able to mark your function noexcept just because you call some standard math function would be counterproductive.

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

#147

Post by tsimionescu »

cesarb wrote: post #114
tsimionescu wrote: post #94

Earlier quoted context omitted.

> A called function can throw through a non-noexcept function to a higher-level exception handler no problem. This is exactly the problem. To have made this a useful feature, it should have been more restrictive: a noexcept function should not have been allowed to call any function or operator or lambda that is not marked noexcept. Some extra syntax to allow function templates to be made "conditionally noexcept" woul…

> Java has the first part down, for the class of checked exceptions: a function that doesn't throw can't call functions that do (except in try/catch blocks, but that's largely irrelevant). That's not actually true, it's possible to do "sneaky throws" ( https://www.baeldung.com/java-sneaky-throws ) of a checked exception from a method which isn't declared to throw that checked exception. The classic example is Class.n…

Sure, but that's essentially the same as using explicit jumps through raw assembly instructions to go around C++'s destructor guarantees. That is, when your Java process runs non-Java code, of course this can defeat certain Java guarantees. No programming language can make promises for semantics of external code like this.

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

#148

Post by account42 »

terrymah wrote: post #108
tolmasky wrote: post #62

Is there any compiler option to have it yell at you if you mark something that can throw as `noexcept`, which seems to be the cause of (at least some of) the slowdowns where the compiler is forced to accommodate with `std::terminate`? I feel like these situations are more commonly mistakes , and not the user wanting to "collapse" exceptions into terminations. So the current approach to dealing with these cases seems…

No, calling throw in a noexcept function is a defined behavior (call std::terminate), and that behavior is not a diagnostic I think maybe WG21 was concerned a compiler engineer would be clever if throwing in noexcept were UB, for example and assume any block that throws is unreachable and could just be removed along with all blocks it postdominates. Compiler guys love optimizations that just remove code. The fastest…

Compilers are allowed to and do diagnose defined but undesirable behavior though, even more so if that's only enabled with an option.

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

#149

Post by account42 »

Maxatar wrote: post #41
quotemstr wrote: post #32

There's a lot of mysticism and superstition surrounding C++ exceptions. It's instructive to sit down with godbolt and examine specific scenarios in which noexcept (or exceptions generally) can affect performance. Read the machine code. Understand why the compiler does what it does. Don't want to invest at that level? You probably want to use a higher level language.

You won't get a sense of how bad exceptions can be by using Godbolt. A lot of the magic of exceptions is handled behind the scenes by the compiler and/or the Itanium ABI. For example one disasterous consequence of using exceptions in GCC is that there is a global application wide lock used to manage stack unwinding. This means that only one single thread can unwind a stack at a time and the lock is held from the star…

No one ever claimed that throwing exceptions is fast and quite honestly you should not care about the performance of that too much and instead make sure that exceptions are supposed to be exceptional.

What is interesting though is the impact of exceptions when they are not being thrown. This includes setup code (mostly avoided by good exception handling implementations) but also inhbited optimization opportunities and executable size bloat.

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

#150

Post by tsimionescu »

account42 wrote: post #146
tsimionescu wrote: post #94

Earlier quoted context omitted.

> A called function can throw through a non-noexcept function to a higher-level exception handler no problem. This is exactly the problem. To have made this a useful feature, it should have been more restrictive: a noexcept function should not have been allowed to call any function or operator or lambda that is not marked noexcept. Some extra syntax to allow function templates to be made "conditionally noexcept" woul…

That would have been too limiting since there are many (e.g. C) functions that can never throw but are not marked noexcept. Not being able to mark your function noexcept just because you call some standard math function would be counterproductive.

There were ways around this. C functions in the standard library could easily be marked noexcept, for one. Extern C could also imply noexcept. Also, explicit try/catch blocks could be required when calling a potentially-throwing function from a noexcept function - slightly annoying, but not a huge problem in practice.

Overall this was just another case of the C++ community's preference for speed over safety and robustness. Nothing new, but still a shame to see that the attitude hasn't changed at all.

Post reply on HN