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

51–60 of 166 posts

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

#51

Post by gumby »

forrestthewoods wrote: post #48
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…

Hard, hard disagree. If you want to support different implementation strategies it needs to be far more piecemeal. Not all or nothing. I mean there's only 3 meaningful implementation - libstdc++, libc++, and MSVC. And they aren't wholly interchangeable! Quite frankly if you value trying different implementation strategies then the C++ model is a complete and total failure. A successful model would have many, many dif…

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.

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

#52

Post by jahnu »

terrymah wrote: post #49
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…

Oh, cool! I googled myself and someone actually archived the slides from the talk I gave. I think it holds up pretty well today https://github.com/TriangleCppDevelopersGroup/TerryMahaffeyC... *edit except the stuff about fastlink *edit 2 also I have since added a heuristic bonus for the "inline" keyword because I could no longer stand the irony of "inline" not having anything to do with inlining *edit 3 ok, also stat…

Props for the edits ;)

I would be very interested in an updated blog post on this if you felt so inclined!

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

#53

Post by Maxatar »

gumby wrote: post #50
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…

> Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. It sure is, and is pretty easy to do. I know companies using EASTL, libcu++, and HPX, as well as more who use Folly and Abseil which have alternate implementations to much of the standard library. These days many languages have a single implementation so some people whose experience is only in those environment comp…

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 your position:

Folly https://github.com/facebook/folly:

"It complements (as opposed to competing against) offerings such as Boost and of course std. In fact, we embark on defining our own component only when something we need is either not available, or does not meet the needed performance profile."

libcu++: https://nvidia.github.io/cccl/libcudacxx/

"It does not replace the Standard Library provided by your host compiler (aka anything in std::)

Incremental: It does not provide a complete C++ Standard Library implementation."

Abseil: https://github.com/abseil/abseil-cpp

"Abseil is an open-source collection of C++ library code designed to augment the C++ standard library. Abseil is not meant to be a competitor to the standard library"

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

#54

Post by [deleted] »

terrymah wrote: post #47
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…

No, we compile in bottom up order, starting with leaf functions, and collecting information about functions as we go. So "not throwing" sort of trickles up when possible to a certain degree. In LTCG (MSVC)/O3 (GCC/Clang) there are prepasses over the entire callgraph to collect this order

[deleted]

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

#55

Post by dataflow »

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 assume the /EHr- flag was introduced to mitigate this, right?

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

#56

Post by [deleted] »

terrymah wrote: post #47
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…

No, we compile in bottom up order, starting with leaf functions, and collecting information about functions as we go. So "not throwing" sort of trickles up when possible to a certain degree. In LTCG (MSVC)/O3 (GCC/Clang) there are prepasses over the entire callgraph to collect this order

[deleted]

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

#57

Post by terrymah »

Arech wrote: post #11
rwmj wrote: post #4

Shouldn't the compiler deduce noexcept for you?

No, it can't do that. My speculation is that likely it is so because in general case this might be a NP hard problem similar to the halting problem https://en.wikipedia.org/wiki/Halting_problem . The best it can do is to say whether a given function is qualified with `noexcept` (see noexcept() operator https://en.cppreference.com/w/cpp/language/noexcept )

Dude I am going to blow your mind

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

#58

Post by [deleted] »

terrymah wrote: post #47
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…

No, we compile in bottom up order, starting with leaf functions, and collecting information about functions as we go. So "not throwing" sort of trickles up when possible to a certain degree. In LTCG (MSVC)/O3 (GCC/Clang) there are prepasses over the entire callgraph to collect this order

[deleted]

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

#59

Post by terrymah »

dataflow wrote: post #55
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 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

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

#60

Post by gumby »

Maxatar wrote: post #53
gumby wrote: post #50

Earlier quoted context omitted.

> Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. It sure is, and is pretty easy to do. I know companies using EASTL, libcu++, and HPX, as well as more who use Folly and Abseil which have alternate implementations to much of the standard library. These days many languages have a single implementation so some people whose experience is only in those environment comp…

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 are, the latter being heavily used in (unsurprisingly) the gaming comunity).

libcu++ is for your target compilation.

As for Folly and Abseil, I wrote "as well as more who use Folly and Abseil which have alternate implementations to much of the standard library" (i.e. not ful drop in replacements).

So really I don't know what your point is: you made an assertion, then replied not to what I actually wrote but by simply doing a quick google search and using that as your conclusion.

I have used all of HPX, Folly and Abseil but I guess the top of a google search result is more authoritative.

Post reply on HN