Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
Date: Thu, 16 Dec 2004 22:33:31 +1300
From: Danny Smith <dannysmith AT clear DOT net DOT nz>
Subject: Re: c++ code executes very slowly - sjlj EH to blame?
To: adam_m_mckee AT yahoo DOT ca
Cc: Cygwin <cygwin AT cygwin DOT com>
Reply-to: Danny Smith <dannysmith AT users DOT sourceforge DOT net>
Message-id: <000901c4e352$4f7d1f40$9d4861cb@DANNY>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit

Larry Hall wrote:
>
>True but the way I read that conversation was that DWARF2
>EH worked if callbacks weren't used or would work with
>callbacks so long as -fexceptions was used.  Maybe I read
>that incorrectly though.

That is correct.  Maybe we can convince ReactOs to release a win32api built
with -fexceptions and DW2 unwind tables.

>>
>>My goal is to build gcc/g++ that use Dwarf2 EH.  A
>>compiler with working EH will be able to run my test
>>program without aborting.  So far I have built several
>>versions of gcc, all of which have the abort() EH,
>>which is equivalent to having _no_ EH in practical
>>terms.
>>
>>Maybe Danny Smith has some thoughts about this, since
>>he has apparently been at least partially successful
>>in getting DWARF2 EH to work on cygwin.
>
>
>Yes, I expect he'll chime in.
>

<ding-dong-lurker.wav>
FWIW, Dwarf2 unwind worked without any complaints (that I am aware of)
from cygwin users in a GCC-3.2 (cygming special) release. One of the two DW2
bug reports by mngw users (stdcall vs fomit-frame-pointer vs
 -mno-accumulate-outgoing-args) has been fixed in GCC.  The other (callbacks
that
throw exceptions from a foreign function) has not

A 4.0 patch to enable DW2 unwind is at:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01989.html

GCC is now in Stage 3 of development cycle (regression fixes only)
I plan to submit a revised patch when 4.0 branches. So maybe 4.1

>
>>Another question for anyone at all: any ideas why sjlj
>>is so crap-tastically slow on cygwin?  I can't believe
>>that sjlj EH has nearly such a huge hit on other
>>targets.  If sjlj it is the sole perpetrator of the
>>slowdown, then it is doing a very very effective job
>>of slowing things down.
>

Depends. If you're app makes only limited use of exceptions, sjlj can be
more efficient. However, since operator new can throw exceptions, the
cost of sjlj can add up very quickly. I think the default use of the
simple new-based allocator in gcc-3.4.x libstdc++ (rather than a more
efficient pool allocator) also compounds the problem.

I wouldn't blame everything on sjlj.  C programs that do any file I/O
are also crap-tastically slow on windows compared to glibc targets.

Danny


--
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/