Re: size of exception handling (Was: performance of exception handling)

On Tue, 12 May 2020, 10:15 Oleg Endo, wrote: > > On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote: > > > > I actually have to build my own toolchain instead of the one provided > > by ARM, because to really NOT use C++ exceptions, you have to recompile > > the whole libstdc++ with

Re: size of exception handling (Was: performance of exception handling)

On 13/05/2020 00:48, Jonathan Wakely via Gcc wrote: On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote: On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: Anyway... If you have to recompile the toolchain, the problem is still there. Most of the people (like 99,666%) will not do that for

Re: performance of exception handling

> 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

Re: size of exception handling (Was: performance of exception handling)

On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote: > On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: > > Anyway... If you have to recompile the toolchain, the problem is still > > there. Most of the people (like 99,666%) will not do that for various > > reasons. Some don't know how, some use

Re: size of exception handling (Was: performance of exception handling)

On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: > > On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote: > > You're talking about C++ exceptions in general, but the problems you > > mention seems to be issues with specific implementation properties. > > Possibly true, but this argument -

Re: size of exception handling (Was: performance of exception handling)

On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote: > You're talking about C++ exceptions in general, but the problems you > mention seems to be issues with specific implementation properties. Possibly true, but this argument - that all the problems are related to specific implementation

Re: size of exception handling (Was: performance of exception handling)

On Tue, 12 May 2020 at 09:17, Freddie Chopin wrote: > The problem with C++ exceptions is that even in the most > trivial of the programs and even if you don't explicitly > use/catch/throw them, they instantly eat around 60 kB of ROM and quite > a lot of RAM. With some hacking you can get down to

Re: performance of exception handling

Thomas Neumann via Gcc writes: >> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate >> implementation in GLIBC creates its own set of advantages and >> disadvantages. > > so what should I do now? Should I try to move the lookup into GLIBC? Or > handled it within libgcc, as I had

Re: size of exception handling (Was: performance of exception handling)

On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote: > > I actually have to build my own toolchain instead of the one provided > by ARM, because to really NOT use C++ exceptions, you have to recompile > the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they > provide the

Re: performance of exception handling

> Some people use exceptions to propagate "low memory" up which > made me increase the size of the EH emergency pool (which is > used when malloc cannot even allocate the EH data itself) ... > > So yes, people care. There absolutely has to be a path in > unwinding that allocates no (as little as

Re: size of exception handling (Was: performance of exception handling)

On Mon, 2020-05-11 at 17:14 +0200, Moritz Strübe wrote: > I just wanted to point out that Herbceptions do not only fix > performance > issues, but also code-size problems. While anything below 4GB of RAM > is > considered under-powered for a PC, typical deep embedded > environments > have

Re: performance of exception handling

On Tue, May 12, 2020 at 8:14 AM Thomas Neumann via Gcc wrote: > > > Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate > > implementation in GLIBC creates its own set of advantages and > > disadvantages. > > so what should I do now? Should I try to move the lookup into GLIBC? Or >

Re: performance of exception handling

> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate > implementation in GLIBC creates its own set of advantages and > disadvantages. so what should I do now? Should I try to move the lookup into GLIBC? Or handled it within libgcc, as I had originally proposed? Or give up due to

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: >> >> * David Edelsohn: >> >> > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc >> > wrote: >> > >> >> My current preferred solution is something that moves the entire code >> >> that locates the relevant FDE

size of exception handling (Was: performance of exception handling)

Hey. Am 11.05.2020 um 15:59 schrieb Thomas Neumann via Gcc: In a way I am disagreeing with the paper, of course, in that I propose to make the existing exception mechanism faster instead of inventing a new exception mechanism. But what I agree on with P0709 is that it is unfortunate that many

Re: performance of exception handling

On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: > > * David Edelsohn: > > > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > > wrote: > > > >> My current preferred solution is something that moves the entire code > >> that locates the relevant FDE table into glibc. This is all

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > wrote: > >> My current preferred solution is something that moves the entire code >> that locates the relevant FDE table into glibc. This is all the code in >> _Unwind_IteratePhdrCallback until the first

Re: performance of exception handling

On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc wrote: > My current preferred solution is something that moves the entire code > that locates the relevant FDE table into glibc. This is all the code in > _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base > call. And

Re: performance of exception handling

* Thomas Neumann: >> Link: >> >> I'm not sure if your summary is correct. > > I was referring to Section 3.2, where Herb says: > > "We must remove all technical reasons for a C++ project to disable > exception handling (e.g., by compiler switch) or ban use of

Re: performance of exception handling

> Link: > > I'm not sure if your summary is correct. I was referring to Section 3.2, where Herb says: "We must remove all technical reasons for a C++ project to disable exception handling (e.g., by compiler switch) or ban use of exceptions, in all or part of their

Re: performance of exception handling

* Thomas Neumann via Gcc: > Currently, exception handling scales poorly due to global mutexes when > throwing. This can be seen with a small demo script here: > https://repl.it/repls/DeliriousPrivateProfiler > Using a thread count >1 is much slower than running single threaded. > This global

performance of exception handling

Hi, I want to improve the performance of C++ exception handling, and I would like to get some feedback on how to tackle that. Currently, exception handling scales poorly due to global mutexes when throwing. This can be seen with a small demo script here: https://repl.it/repls