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

81–90 of 166 posts

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

#81

Post by pjmlp »

terrymah wrote: post #42

Oh man, don't get me started. This was a point in a talk I gave years ago called "Please Please Help the Compiler" (what I thought was a clever cut at the conventional wisdom at the time of "Don't Try to Help the Compiler") I work on MSVC backend. I argued pretty strenuously at the time that noexcept was costly and being marketed incorrectly. Perhaps the costs are worth it, but none the less there is a cost The reaso…

> Anyway. My point is, we need more backend compiler engineers on WG21 and not just front end, library, and language lawyer guys.

Even better, the current way of working is broken, WG21 should only discuss papers that come with a preview implementation, just like in other language ecosystems.

We have had too many features being approved with "on-paper only" designs, to be proven a bad idea when they finally got implemented, some of which removed/changed in later ISO revisions, that already prove the point this isn't working.

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

#82

Post by pjmlp »

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…

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

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

#84

Post by flamedoge »

aw1621107 wrote: post #69
terrymah wrote: post #42

Oh man, don't get me started. This was a point in a talk I gave years ago called "Please Please Help the Compiler" (what I thought was a clever cut at the conventional wisdom at the time of "Don't Try to Help the Compiler") I work on MSVC backend. I argued pretty strenuously at the time that noexcept was costly and being marketed incorrectly. Perhaps the costs are worth it, but none the less there is a cost The reaso…

> I argued then that if instead noexcept violations were undefined, we could ignore all this, and instead just treat it as the pure optimization it was being marketed as (ie, help prove a region can't throw, so we can elide entire try/catch blocks etc). Do you know if the reasoning for originally switching noexcept violations from UB to calling std::terminate was documented anywhere? The corresponding meeting minutes…

> did not restrict optimization unnecessarily.

well clearly there is a cost

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

#85

Post by Arech »

terrymah wrote: post #59
dataflow wrote: post #55

Earlier quoted context omitted.

I assume the /EHr- flag was introduced to mitigate this, right?

Nah that was mostly about extern "C" functions which technically can't throw (so the noexcept runtime stuff would be optimized out) but in practice there is a ton of code marked extern "C" which throws

> in practice there is a ton of code marked extern "C" which throws

Obviously, a random programmer could do any evil things, but does that apply to standard code, such as C standard library used from C++?

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

#86

Post by mcdeltat »

terrymah wrote: post #42

Oh man, don't get me started. This was a point in a talk I gave years ago called "Please Please Help the Compiler" (what I thought was a clever cut at the conventional wisdom at the time of "Don't Try to Help the Compiler") I work on MSVC backend. I argued pretty strenuously at the time that noexcept was costly and being marketed incorrectly. Perhaps the costs are worth it, but none the less there is a cost The reaso…

> 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. Presumably the compiler is already moving your exception throwing instructions off the happy hot path.

Very very basic test with Clang: https://godbolt.org/z/6aqWWz4Pe Looks like both variations have similar code structure, with 1 extra instruction for noexcept.

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

#87

Post by hoseja »

forrestthewoods wrote: post #27
chipdart wrote: post #23

Earlier quoted context omitted.

> It's a compromised and goofy implementation with lots of warts. I don't think this case qualifies as an example. I think the only goofy detail in the story is expecting a random number generator to be non-random and deterministic with the only conceivable usecase being poorly designed and implemented test fxtures. > What's the point it in having a /standard/ library then? The point of standardized components is to…

> The point of standardized components is to provide reusable elements that can be used across all platforms and implementations, thus saving on the development effort of upgrading and porting the code across implementations and even platforms. It's a shame that C++'s "standardized" components ARE COMPLETELY DIFFERENT on different platforms. Some of the C++ standard requires per-platform implementation work. For exam…

std::deque, a container with some quite useful theoretical properties, is completely unusable because the node size is not specifiable by the user and MSVC chose 16 bytes (I think, insanely small nonetheless).

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

#88

Post by hifromwork »

mcdeltat wrote: post #86
terrymah wrote: post #42

Oh man, don't get me started. This was a point in a talk I gave years ago called "Please Please Help the Compiler" (what I thought was a clever cut at the conventional wisdom at the time of "Don't Try to Help the Compiler") I work on MSVC backend. I argued pretty strenuously at the time that noexcept was costly and being marketed incorrectly. Perhaps the costs are worth it, but none the less there is a cost The reaso…

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

Pick a different architecture - anything 32bit. Exception handling on 64bit windows works differently, where the overhead is in the PE headers instead of asm directly (and is in general lower). You don't have the setup and teardown in your example

Throwing exception has the same overhead in both cases. In case of noexcept function, the function has to (or used to have, depending on architecture setup an exception handling frame and remove it when leaving.

>Naively it'd seem like without noexcept, you raise the exception; and with noexcept, you call std::terminate instead

Except you may call a normal function from a noexcept function, and this function may still raise an exception.

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

#89

Post by shultays »

I can't find the explanation on why noexcept could hurt performance. One reason I can see itt is some containers like unordered_map can inline the hash along with the key with noexcept, which may not worth additional memory overhead if the hashing is relatively cheap. He talks a bit about it in "Intel+Windows+MSVC" but not much info. I wish there was

noexcept helps in some cases that author doesn't seem to be using and any performance gain or loss is basically due to some (unrelated?) optimization decisions the compiler takes differently in noexcept builds if I am understanding correctly?

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

#90

Post by gpderetta »

Maxatar wrote: post #64
gumby wrote: post #60

Earlier quoted context omitted.

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

My point is simple, you are poorly informed on this topic and should refrain from speaking about it. None of the libraries you listed are independent implementations of the standard library let alone source compatible. EASTL does not claim to be an implementation of the C++ standard library, its claim is that it is an alternative to the C++ standard library. Perhaps the distinction is too subtle for you to have actua…

I'm pretty sure that gumby forgot more about c++ and c++ implementations than the rest of us will ever know.
Post reply on HN