X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Message-ID:	<46DFFE96.70907@ajrh.net>
Date:	Thu, 06 Sep 2007 09:20:22 -0400
From:	Anthony Heading <anthony AT ajrh DOT net>
User-Agent:	Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Slowness problem due to sjlj-exceptions for Octave
References:	<20070905080321 DOT 29259AB0 DOT matsuoka AT mol DOT nagoya-u DOT ac DOT jp> <46DE0C86 DOT 61C0ABB0 AT dessent DOT net>
In-Reply-To:	<46DE0C86.61C0ABB0@dessent.net>
X-Junkmail-Status:	score=10/50, host=mr02.lnh.mail.rcn.net
X-Junkmail-SD-Raw:	score=unknown, refid=str=0001.0A090209.46DFFEAD.0006,ss=1,fgs=0, ip=207.172.4.11, so=2006-12-09 10:45:40, dmn=5.3.14/2007-05-31
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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/

- Raw text -