From: jeffdbREMOVETHIS AT netzone DOT com (Mikey) Subject: MUCH faster cygwin.dll was RE:Time and motion studies of gcc and egcs and LCC 14 Feb 1998 06:32:50 -0800 Message-ID: <34e5a60a.56566602.cygnus.gnu-win32@smtp.netzone.com> References: <199802021515 DOT IAA08872 AT chorus DOT dr DOT lucent DOT com> Reply-To: jeffdbREMOVETHIS AT netzone DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gnu-win32 AT cygnus DOT com 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 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 >"gnu-win32-request AT cygnus DOT com" 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. (jeffdbREMOVETHIS AT netzone DOT com) delete REMOVETHIS from the above to reply Mikey - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".