Hacker News Reader

Comment by drmeister | Hacker News Reader

Threads are very expensive if you start throwing C++ exceptions within them in parallel. You see the overall time to join the threads increases with each thread you add. There is a mutex in the unwinding code and as the threads grab the mutex they invalidate each other's cache line. I wrote a demo to illustrate the problem https://github.com/clasp-developers/ctak

MacOS doesn't have this problem but Linux and FreeBSD do.

View on HN

There’s an easy optimization to avoid inspecting every frame when unwinding which c++ could not implement (for policy reasons) though a platform could: add a pointer to the next frame that needs unwinding to the frame setup. This is like move elision.

If my caller has destructors to run or a catch clause this pointer is null and inspection proceeds as normal. If It does not it stores the value from its frame there. Then if I throw an exception I jump to the next frame that needs inspection; if I don’t then any throw further down the call stack won’t even look at me.

The C++ standard can’t call for this because of the “zero cost if you don’t use it” rule. But a Linux ABI could. The MacOS takes advantage of this kind of freedom.

This sounds a lot like the SJLJ runtime model that was used in G++ for years.

> The C++ standard can’t call for this because of the “zero cost if you don’t use it” rule. But a Linux ABI could. The MacOS takes advantage of this kind of freedom.

That's not really true. It has nothing to do with the standard. It has everything to do with the compiler's users complaining about the performance hit relative to DWARF EH. It is part of the social contract between the standards body, the compiler author community, and the user community that unused features don't cost us in runtime performance.

Yes, it's similar I suppose, though much lower overhead. I was a bigger advocate for frame inspection than Michael was in the early years because of my Lisp background. He was (correctly) more concerned with performance.

As for "policy" vs "social contract" I think we basically agree.

This sounds interesting - thank you! We need to interoperate with C++ - so we couldn't use this, could we? We could add this pointer to our own frames but C++ frames won't have this info - so I'm not sure how they would interoperate. We need to be able to throw an exception and invoke both Clasp frame cleanups and C++ frame cleanups up the stack. We have a crazy mix of C++ and CL frames on the stack at any time.

Sure you could. You presumably already have a mechanism for doing frame unwinding either via compatibility with the C++ runtime's throw() implementation or by supplying your own. So for your own stack frames you can do what you like. Exceptions raised by c++ code called from lisp would also work the same way as they do now.

And when you are unwinding a lisp->C++ boundary (that is, lisp code called by a C++ function) you are free to do what you like until you get to the first Lisp frame; if it doesn't have an unwind-protect then its "ignore me" pointer just points up to its caller, which is examined by the C++ runtime anyway.

The nice part of that second paragraph is that if that first lisp callee was called by a non-c++ function (say a fortran function) you might even have an opportunity to set the "parent frame for inspection pointer" to skip over all the fortran frames and point directly to the lowest C++ function below you...which you could manage via a small change to gold or llvm-ld.

To be fair: very few C++ applications are limited by exception performance, it's a feature that's very much out of favor at the moment. So penalizing everyone else (despite the fact that most new code doesn't use them, it's not at all uncommon to find projects with exception generation enabled for the benefit of one library or two) to make parallel exceptions faster actually does seem like a bad trade to me in the broad sense.

Apple does indeed have more freedom, and it may be that specific MacOS components need this in ways that the general community doesn't seem to. But I'd want to see numbers from a bunch of real world environments before declaring this a uniformly good optimization.

> it's a feature that's very much out of favor at the moment.

I'm glad if it is so. Exceptions should actually be "exceptional" and not the part of the normal execution flow. Whoever has other ideas has the wrong model of what, at the lower levels, exceptions actually do.

> To be fair: very few C++ applications are limited by exception performance, it's a feature that's very much out of favor at the moment.

It is distressing that Sutter's survey showed that half the respondents had to disable exceptions for part of all the code. I've often heard the argument "well google's coding standard prohibits exceptions" which is bizarre, as google's standard says "exceptions are great but we have some legacy code that can't use them, so we're stuck"

The biggest argument seems to be that they are expensive, which is crazy because there's no cost if you don't raise one and if you do you're already in trouble and generally have plenty of time to deal with it (this is different from, say, Lisp signalling which not only permits continuing (!) but is on theory supposed to be common. Probably a mistake in retrospect). But they allow you to make the uncommon stuff uncommon (as opposed to error codes which must be sprayed like shrapnel through your code).

There are two legit arguments against exceptions: one is when you are constrained in space (e.g. embedded systems) and/or time (hard realtime systems that need predictable timing, even if it is slower). The other is a philosophical argument that it embodies a second, parallel flow of control. Since C++'s exception system is an error system only, and since destructors are run automatically, it's hard for me to find this second argument convincing.

Sometimes I miss C++'s flexibility from the managed languages that usually use, then I remember that the community is now driven by the performance at all costs crowd, without exceptions, RTTI, STL and let that thought go.

That is not the C++ I enjoy using, rather the language I got to love via Turbo Vision, OWL, VCL, MFC, Qt, which is not what drives the language nowadays.

Yeah, when the moderates move out, the hard core that remains swings towards what makes C++ unique, and that's not general purpose application programming and language features that support it.

Which looking from its use in mainstream OS SDKs means drivers, composition engine, shaders and real time audio engines, the SQL of systems programming, kind of.

I wouldn’t characterize that group as “the community”. True there are a lot of such people, mostly clustered In the game industry where superstition is rife.

Take a look At C++ (or c++ 20!) as if it were a brand new language you’d never seen before and forgetting that it’s name includes “c”. That language is a pretty clean, expressive and straightforward language IMHO. I like programming in it.

It’s not claiming it’s unicorns farting rainbows, but it’s definitely pretty good.

If the community wasn't busy discussing those issues, and constexpr of all things, we would already have reflection, with a concurrency and networking story that isn't put to shame for what Java 5 already had, let alone in modern managed languages.

Yeah, if everyone plays ball, it might come in 5 years from now, assuming C++23 gets done on time, plus the compiler support stabilization.

Right now SG14 seems to drive some of those decisions, at least from outside.

Those are important issues and people who care about them work on them and come to committee meetings. There is less consensus on the concurrency and networking side which I also find frustrating but as I’m not pushing those balls forward I can’t complain. I do think at least that the direction they’re moving in is a fruitful one.

The standard can move quickly: consider formatted output which lingered unchanged with a broken model but was rapidly reformed when someone with a good model and implementation was encouraged to come forward. Admittedly a smaller topic than concurrency or networking!

Right now, the way I see it, I rather help the managed languages I work on reach the point where binding to C++ is kind of last option when nothing else helps.

The other language communities manage to drive language progress over the Internet, which apparently ISO has yet to get in touch how it goes.

C++ does this as well, for example with boost, where several things that entered the standard got their start. And the format example I gave. It’s the ISO blessing that is complex, but also acts as a forcing function tromtrhnto make new features as orthogonal as possible. Sure, it’s not to everybody’s taste, but you don’t need to follow ISO if you don’t wish to.

That seems like a misconception about the driving forces behind C++ today.

Not when one looks into the recent ABI discussions.

You mean a refusal to break ABI?

Yes, as means to achieve performance improvements that aren't that relevant to average Joe C++ dev.

The one doing application stuff in Qt, MFC, wxWidgets.

Or those like myself, where C++ only matters as means to implement native bindings to system libraries, or GPGPU shading languages based on C++.

Well I can afford a complete ABI break (complete) given the kind of code I work on. Most people cannot. Binary incompatibilities are very hard for most people to manage.

So I would benefit from any number of abi-breaking proposals but can understand the committees reticence.

To be honest it is hard to not break ABI. First you almost surely need to use PImpl and second hope a compiler upgrade keeps the standard library ABI compatible(eg ABI version flags in gcc). For a good look at how hard this is look at breakages in gentoo. This is basically the reason the greater open source community has their libraries in C: stable ABI, and consequently language bindings. Unless i am missing something big the concept of ABI stability in C++ is an art and requires a lot of discipline. At the top of my head only KDE was somehow successful but have a look at their guidelines[1]: again it requires a lot t of discipline.

Also I believe that ABI compatibility with binaries compiled with different compilers also is complicated by things like name mangling conventions which are not common between compilers.

There are so many things that can go wrong that the people i know that rely on ABI compatibility in C++ make a diff of their objdump output a ci test. Sometimes they get more paranoid and send me an assembly diff when they are suspicious(a compiler upgeade generated different jump prolog:) ). Ridiculous compared to the price of just running the compile again. The fact we control the whole machine's os image even makes it harder to understand... Oh man the pain I have...

My apologies if my text is weird but proof reading in a phone is hard.

[1]https://community.kde.org/Policies/Binary_Compatibility_Issu...

Hmm got down voted. Would it be possible to elaborate on what is wrong with my post? Kind of new to HN so I would be glad to learn what I did wrong.

Per HN's own guidelines your post did not deserve downvoting.

Unfortunately some people do use downvoting to mean "I disagree", presumably based on the convention of some other forum. There's not much to be done about that except upvoting posts you see have been unfairly downvoted.

> which is crazy because there's no cost if you don't raise one

This is just false in the general case. The presence (potential or actual) of exceptions often just serves as an optimization barrier in current compilers. That's not to even invoke bizarre but not infrequent issues like this [1]. I too have had codebases that miraculously sped up upon disabling exceptions despite not throwing anything. Identifying the exact causes of these situations is hard and typically not done, because it's far easier to just add a compiler switch and pretend there are no exceptions in C++ and get back to work.

Many people in performance sensitive domains just don't find it remotely worthwhile to care about features that have these sorts of difficult to predict and debug costs. When your workflow already consists of writing highly explicit, simple to reason about code that you frequently inspect in disassembled form, exceptions (and RTTI for a host of obvious reasons) are the last thing you'd want to enable. At best it's just extraneous noise in the assembly, at worst you take a sizable perf hit and have no idea why.

[1] https://twitter.com/timsweeneyepic/status/122307740466037145...

We need sample code for stuff like this so they can be referred back to as canonical examples. Frequently asserted C++ misconceptions?

This description of C++ usage you gave:

A workflow consisting of writing highly explicit, simple to reason about code that you frequently inspect in disassembled form

Is possibly the most descriptive and succinct description of my coding practice. I really like this formulation and I am going to shamelessly steal it in the future, repeatedly.

I'm curious what features of c++ you use and like if you would prefer it over c for this use case.

TL;DR I don’t really use any substantial feature not in C, and basically code C++98, with a few dashes of C++11.

As far as what I’d consider frequent use for me, the only feature I use heavily is namespacing (and that is really only for personal organizational benefits). I do take advantage of standard templated containers and classes when I think they are the right call. Generally, the use of classes and associated method mechanisms are really only used for specific circumstances (which are purely aesthetic for me), and I certainly lean toward custom containers if I can. I do use operator overloading for math, but that’s about it. It is pretty rare for me to use any inheritance, virtual functions, etc, and I don’t think I have ever programmed any exceptions, but maybe some libraries have them, same for RTTI. I do use BLAS, and some other template based libraries.

I don’t use much from after C++98, but I do occasionally dip into C++11 for constexpr. I don’t ever use auto or decltype and I may have looked at range-based fors, but they aren’t used anywhere I can recall.

I think if I could have actual namespaces, instead of space_variable style, C would do it for me. I certainly like that restrict is part of the language, not just a compiler intrinsic. But, and it is a big but, while Clang/llvm, GCC (for the most part) and some proprietary C compilers are good enough for my purposes, MS’s C compiler is barely mediocre as far as I’ve heard (I just went with common talking points when I decided to go down the C++ route, and haven’t actually tested equivalent implementations). Also, while making shim layers is possible, C++ libraries are widespread and common, and just using C++ is less friction and maintenance.

If it isn’t obvious from all of that, my coding style in C++ is basically a rip-off if Mike Acton’s CPPCon talk in 2014. If I want anything more abstract for some reason, I’ll use Python or Haskell or Racket (and recently Ocaml).

Writing exceptions-safe code is not free in itself. Surely one can do it, but it requires more mental energy to write and even more efforts to review the code.

You shouldn't use exceptions in cryptography as well. There are constant-time concerns and dumping sensitive data in the heap concerns at the very least.

Any idea why Darwin is beating Linux and FreeBSD here? Are they doing something different that could/should be implemented in the others?

I believe Darwin has a special unwinding ABI that it uses.

> start throwing C++ exceptions

Well, don't. "Exception-based programming" is an anti-pattern. Exceptions should be thrown in, well, exceptional situations.

They were using it in another language's runtime. Idiomatic advice like that doesn't always transfer.

Limiting exceptions to handle exceptional events is not idiomatic advice, it's stating their usecase,and the whole reason they exist.

It is literally idiomatic advice. Like what's your definition for "idiomatic" and how doesn't that apply?

Did gcc/libstdc++ have the same problem? The report you link is for clang, it looks like.

Yes, gcc/libstdc++ have the same problem. That's where I saw it first and then I tried llvm/libunwind and saw the same thing.

What's the actual lock on? The unwinding shouldn't involve shared mutable state (as someone who's been deep into the DWARF unwinding VM bytecode).

In libgcc it's in Unwind_Find_FDE - we think it's a lock around walking the loaded dynamic libraries. I haven't personally dug much deeper into it but my folks here and the llvm engineers seem to be pretty certain that's the problem (this: https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-...). Right now we are rearranging our compiler so we throw fewer exceptions because you don't have to optimize things that you don't do :-).

Looks to me like it only tries to protect the building of the shared / sorted "seen_objects". You don't want two threads rebuilding it at the same time. Although there must be a way to work around this. Maybe something like optimistically walk through the seen list, then grab the lock to update and walk again without a lock? You should be able to safely walk a linked list forwards even with another thread inserting into it, right?

There is some work libc size to make the lock optional and enabling it only at the first dlopen.

Edit: last time I investigated the issue ended up here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744

I think that this is a lock around dlopen(). dlopen changes the list of mapped objects (and therefore, the mapping from instruction pointer to unwind information).

Unrelated to this thread, but are you still working on the matter compiler project?

That's the point of everything. We have spun up a company and big things are in the works: http://www.thirdlaw.tech/

Are you calling the software the "matter compiler" or is a "matter compiler"/"nanofactory" an eventual end goal of the project?

Wow, I wouldn't have guessed that! Nice data!

Thank you. We have developed a Common Lisp implementation that uses LLVM and interoperates with C++ and uses C++ exception handling to unwind the stack. Common Lisp code relies on stack unwinding a fair bit. Imagine my surprise when my fancy multi-threaded compiler can't get out of first gear (tops out at ~150% cpu) on Linux. Sheesh.

I’ve been really interested in clasp; what’s the current state? Can’t see any recent posts that summarize it.

It's going well. I'll post something soon. We've just been working on it quietly. We have multithreading, unicode, cffi etc, good debugging support, cross-language profiling and more.

What about Windows?

Reply on news.ycombinator.com