This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Slowness problem due to sjlj-exceptions for Octave


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]