Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <4298F195.9090600@familiehaase.de> Date: Sun, 29 May 2005 00:32:53 +0200 From: "Gerrit P. Haase" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: Cygwin Subject: Re: Serious performance problems (Gerrit/Danny please comment) References: <000b01c563c7$f4456f00$976d65da AT DANNY> In-Reply-To: <000b01c563c7$f4456f00$976d65da@DANNY> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Danny Smith wrote: > Re: Serious performance problems (Gerrit/Danny please comment) > From: Christopher Faylor > To: cygwin at cygwin dot com > Date: Sat, 28 May 2005 14:57:20 -0400 > Subject: Re: Serious performance problems (Gerrit/Danny please comment) > References: > > Reply-to: cygwin at cygwin dot com > > -------------------------------------------------------------------------------- > > >>On Sat, May 28, 2005 at 01:24:31PM +0200, Vaclav Haisman wrote: >> >>>Somebody mentioned that malloc implementation could be the problem. Dunno. I >>>has also crossed my mind that another difference between FreeBSD and Cygwin > > is > >>>implementation of C++ exceptions. Maybe the SJLJ implementation that Cygwin >>>AFAIK uses has too big overhead. >> >>To test this theory, I just tried replacing Cygwin's "Unwind" functions >>with those from mingw and saw a noticeable speed up in the execution of >>this program. I did this by extracting the contents of mingw's libgcc >>to a directory and then including unwind-c.o and unwind-sjlj.o on the >>command line when linking the test case. I had to modify the test case >>by adding these two lines to the bottom: >> >> int __mingwthr_key_dtor; >> int _CRT_MT; >> >>to avoid undefined symbol errors so this is obviously not intended as a >>complete solution. >> >>On doing this, the program went from taking 25 seconds to execute to >>taking 7 seconds to execute. That's still 4x slower than mingw but it >>is, nonetheless, a noticeable difference. >> >>Gerrit and Danny do you know what the difference between the mingw and >>cygwin implementations of these functions might be? >> > > > I too suspect sjlj exceptions to be the problem. This has already been > reported on GCC lists: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563 > > The sjlj overhead affects both cygwun and mingw, but cygwin has the > additional overhead of posix threads to ensure thread-safe allocation > and destruction of structures used by exception handling, while mingw > uses win32api directly > (In CRT_MT == 0 case, it doesn't even bother cleaning up) As I thought before, the only difference is buried in w32-shared-ptr.c: $ g++ -o cygspd-mingw cygspd-mingw.o $ time ./cygspd-mingw cygspd.dat real 0m51.071s user 0m50.108s sys 0m0.046s cgf, your box must be really fast if this lasts half the time than it lasts for me and I have already a really fast box;) $ g++ -o cygspd-mingw cygspd-mingw.o w32-shared-ptr.o $ time ./cygspd-mingw cygspd.dat real 0m8.049s user 0m7.015s sys 0m0.093s Is this call in w32-shared-ptr.c really needed here? /* recreate atom after fork */ pthread_atfork (NULL,NULL,__w32_sharedptr_fixup_after_fork); > Enabling Dwarf2 exceptions helps a lot, since it eliminates the need for > the code for these object in f function prologue. Sigh! Gerrit -- =^..^= -- 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/