Subject: MUCH faster cygwin.dll was RE:Time and motion studies of gcc and egcs and LCC
From: [email-masked] (Mikey)

14 Feb 1998 06:32:50 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [email-masked]

Possibly everyone already thought of this
after Sergey's comments about time spent in
relocation processing during configure, but for those
who haven't, it works!!

cd .../H-i386-cygwin32/bin
cp cygwin.dll cygwin.striped_dll
strip.exe --strip-all --remove-section=.reloc cygwin.striped_dll
exit

from explorer/dos box
rename cygwin.dll cygwin.B18_dll
( or cygwin.cool_dll as appropriate :)
rename cygwin.striped_dll cygwin.dll
start bash
at least 30-40% speed increase on EVERYTHING ;^)

Geoff I would recommend using --image-base=0x78000000
for cygwin.dll same as MSVCRT.DLL which is relocatable
and should never be loaded in the same VM anyway.

WARNING all other dll's you build for use with this cygwin.dll
will have to be relocatable!!!! or use an image base
other than 0x10000000. 0x10070000+ should be safe.

Part of the reason that cygwin32 looks so slow on
win32, may be that the low level memory access
routines in newlib and libiberty <string.h> are not x86 optimized

memcpy strcpy etc. are all, as far as
I have looked at them written in c to use int copy routines
which dosen't look to me like a very efficient solution.

Maybe cc1 should optimize these to use MOVSxx SCASxx STOSxx etc.
but it dosen't seem to, I just rebuilt newlib/ coolview/ and looked
at the disassembly of the routines in newlib/libc/string, and
they look very inefficient to me. ;^).

On Mon, 2 Feb 1998 08:15:22 -0700, you wrote:

>
>>It occurred to me
>>afterwards that the probable reason for this is linking to a DLL library
>>or libraries for time-critical code.  If you get a profiler program that
>>lets you know where gcc spends its time, I think you'll find that gcc is
>>spending that extra time thunking back and forth between cygwin.dll.
>
>I don't think that the overhead of getting into a DLL is all that great, so
>I think that the performance hit is somewhere else, like inside cygwin.dll
>and NT itself.  The cost to enter a DLL is an additional jump instruction
>(indirect through the linkage pointer).  To return is no cost.  Granted, this
>does bring an additional page into the working set (or two, actually, because
>the linkage pointer is probably on a different page), but if the calls are
>frequent, it should not be flushed frequently, so the page fault cost is
>not very great either.
>
>On Linux, is gcc linked with a static library or a shared library?  The cost
>to enter a shared library is similar to a DLL.  Of course, cygwin32 has to
>call into kernel32 & other NT DLLs, so there is a multiplication of costs
>for cygwin32, but I still don't think that the DLL linkage costs are very
>great.
>
>marcus hall
>-
>For help on using this list (especially unsubscribing), send a message to
>"[email-masked]" with one line of text: "help".

=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.

Microsoft Windows, a platform without a leg to stand on.

([email-masked])
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".