> Just echoing what David said really, but: if the libgcc changes > are expected to be portable beyond glibc, then the existence of > an alternative option for glibc shouldn't block the libgcc changes. > The two approaches aren't be mutually exclusive and each approach > would achieve something that the other one wouldn't.
to make this discussion a bit less abstract I have implemented a prototype: https://pastebin.com/KtrPhci2 It is not perfect yet, for example frame de-registration is suboptimal, but it allows us to speak about an actual implementation with real performance numbers. To give some numbers I take my silly example from https://repl.it/repls/DeliriousPrivateProfiler with 6 * 1,000,000 function calls, where half of the functions throw, and I execute it either single threaded or multi-threaded (with 6 threads) on a i7-6800K. Note that the effects are even more dramatic on larger machines. The "old" implementation is gcc 9.3., the "new" implementation is gcc git with the patch linked above. (Note that you have to both use the patched gcc and use LD_LIBRARY_PATH or similar to force the new libgcc when repeating the experiment). The execution times are: old approach, single threaded: 4.3s old approach, multi threaded: 6.5s new approach, single threaded: 3.9s new approach, multi threaded: 0.7s This is faster even when single threaded, and it is dramatically faster when using multiple threads. On machines where atomics are supported raising an exception no longer uses a global mutex (except for the first exception after new exception frames were added), and thus exception processing scales nicely with the threaded count. The code also handles the out-of-memory condition, falling back to linear search in that case (just as the old code). Of course this needs more polishing and testing, but would something like this be acceptable for gcc? It makes exceptions much more useful in multi-threaded applications. Thomas
