X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <COL101-W1796553906F07DD5A0E579E64F0@phx.gbl>
From: Jay <jay DOT krell AT cornell DOT edu>
To: <pkc AT f1-photo DOT com>, <cygwin AT cygwin DOT com>
Subject: RE: Slow fork issue - Win x64
Date: Thu, 18 Sep 2008 09:07:09 +0000
In-Reply-To: <1221716111.21095.ezmlm@cygwin.com>
References: <1221716111 DOT 21095 DOT ezmlm AT cygwin DOT com>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id m8I98CH0030829


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