This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: MUCH faster cygwin.dll was RE:Time and motion studies of gcc and egcs and LCC


I looked at the disassembly of the routines in the .o's.
even if they do get inlined, the routines would be much
faster using MOVSxx STOSxx etc. IMHO especially talking about
fork() which currently does byte copies of the entire data section
of each .dll, this is part of the
reason that djgpp runs so much faster,
the code in gcc/cc1 etc. is all the same (obviously :), but DJ or somebody
optimized the libc routines. don't know about libiberty.

I realize that newlib/ is strictly a cygnus
effort.  I would personally like to see cygwin.dll
built as a wrapper for msvcrt.dll instead of newlib.
Let MS worry about the upgrades ;^).

On Sun, 15 Feb 1998 23:50:49 GMT, you wrote:

>In article <34e5a60a.56566602@smtp.netzone.com>,
>Mikey <jeffdbREMOVETHIS@netzone.com> wrote:
>>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 ;^)
>
>*I* hadn't thought of this, and I just tried it.  It works!  Brilliant!
>
>>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.

About 1 1/2 years ago late B16/early B17.1, Geoff was asking about
a safe location for a nonrelocatable cygwin.dll.
So above I was talking about a permanent change to Makefile.in

>
>You can move the base yourself if you have MSVC's editbin program:
>
>	editbase /rebase:base=0x78000000 cygwin.dll
>
>Do this before you strip the .dll...
>
>>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. ;^).
>
>Did you look at the routines themselves or at actual code in cygwin
>which calls them?  I was under the impression that GCC inlined some
>of the string/memory routines if the proper optimization was specified.

from the gcc man page
       -O3    Optimize  yet  more.  This  turns on everything -O2
              does, along with  also  turning  on  -finline-func-
              tions.
       -finline-functions
              Integrate all simple functions into their  callers.
              The  compiler heuristically decides which functions
              are simple enough to be worth integrating  in  this
              way.

              If  all  calls  to a given function are integrated,
              and the function is declared static, then GCC  nor-
              mally  does  not  output  the function as assembler
              code in its own right.
       -Winline
              Warn  if  a function can not be inlined, and either
              it was  declared  as  inline,  or  else  the  -fin-
              line-functions option was given.
       -fkeep-inline-functions
              Even if all calls to a given function are integrat-
              ed, and the function is declared static,  neverthe-
              less output a separate run-time callable version of
              the function.
       -mno-memcpy
              The -mmemcpy switch makes all block moves call  the
              appropriate  string  function (memcpy or bcopy) in-
              stead of possibly generating inline code.

sadly the default build uses -O2

BTW "simple enough" seems to be about 3-4 lines of code.
grep -l in the /obj/gcc and /obj/winsup dir shows that the memcpy and bcopy 
routines are called, not inlined, even if you use -O3.

=====================================================
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@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]