Slowness problem due to sjlj-exceptions for Octave

Anthony Heading anthony@ajrh.net
Thu Sep 6 13:20:00 GMT 2007


Brian Dessent wrote:
> The choice to ship gcc configured for SJLJ is because it is the only way
> to guarantee correct behavior in all cases.  [... elided... ] EH across
> shared libraries will always be broken in the case of static libgcc et
> al.  (The same is true on other platforms like Linux, so it's not a
> unique situation.  But MinGW is kind of unique as its users expect to
> build standalone apps that don't require DLLs like cygwin1.dll or
> libgcc.dll.)

That's a really informative overview - thanks.

FWIW, I discovered that much of my own C++ code ran slower by a factor 
of three, and it was due to SJLJ exceptions.  So I used Danny's patch 
with upstream GCC4, which fixed the problem.  (I also experimented 
vaguely successfully with building a cross-compiler to native windows, 
modulo the exception limitations that you describe.) This is all tricky 
stuff though, and it would be really helpful if some form of out-the-box 
compiler didn't incur the show-stopping speed penalty.

In my case, principally using cygwin to port Unix code to run on 
Windows, it's quite common already to have taken care not to throw 
exceptions across library boundaries:  indeed, Unix libraries have often 
been compiled with totally different compilers using C as the lingua 
franca ABI.  This has never been exception-safe, and there was no 
expectation that it should be.

So it seems to be a pretty high hurdle to have full windows 
compatibility here, and frustratingly I don't really understand the aim 
or the purpose.  For code that is going to link with Windows/msvcrt, 
using mingw is an obvious first choice, and the correctness guarantee is 
likely critical.   For code that is going to link with cygwin1.dll, I'm 
having a hard time seeing where this capability is needed: the anecdotal 
evidence on this list and others over the past few years seems to agree 
with my own perception that the speed performance loss is conceded to 
solve a recondite theoretical issue for most Cygwin users.   Not to say 
that the constraint isn't technically real, but it it worth killing the 
Cygwin platform for Octave et al when mingw is available for those that 
need it?

Anthony

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list