This is the mail archive of the cygwin 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]
Other format: [Raw text]

RE: Slow fork issue - Win x64


> --Forwarded Message Attachment--
> Date: Wed, 17 Sep 2008 20:41:40 +0200
> From: pkc
> To: cygwin
> Subject: Slow fork issue - Win x64


> I have been noticing extreme slowdowns in vista/2k8 64 with latest cygwin 1.5.

> while (true); do date; done | uniq -c

> On windows 2008 64bit:
>      11 Wed Sep 17 20:35:27 RDT 2008

> On windows XP SP3 32bit:
>      50 Wed Sep 17 20:35:43     2008

> At first I thought it was a syswow64(windows on windows 64, the windows 32 subsystem of windows 64bit)
> that was causing the issue since cygwin is 32 bit.


"Me too".
I've been building gcc a lot lately on AMD64/XP and was surprised
that it /seemed/ much faster on x86/XP.
Different machines, but I didn't think that much different.

Your test gets me under 10 always on AMD64, and usually around 30 on x86.
More digging would be required.

I've been experimenting with ways to speed up fork.

   1) implement it like how the text file describes a way to do vfork -- with setjmp/longjmp  
   I gave up on that. 
   I realize fork and vfork have different meaning. I figured most forks could be vfork, though
   it turns out, maybe not. Bash for example runs a fair amount of code between fork and exec.
   Rather than copy the fd table around, I tried changing close to close-on-exec that occured
   between the fork and exec, but ultimately, didn't work out, not easily.


   2) Using the fork support in NtCreateProcess. Haven't finished that -- need
   to probably zero and reinit Win32 .dlls' .bss/.data, while leaving Cygwin .dlls alone.
   So still slow memcpy-ish work to do. I suppose one could even add it up at fork time
   and decide which might be faster..


 but maybe merely bringing up AMD64 up to the speed of x86 would suffice. 


 Wow64 is a fairly thin layer. 
 It has to translate kernel calls, widening/narrowing integers/pointers 
 and translating paths between "system32" and "syswow64". 
 When your code is running without making kernel calls, it runs at full speed.


 - Jay

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


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