* RE: Slow fork issue - Win x64
[not found] <1221716111.21095.ezmlm@cygwin.com>
@ 2008-09-18 11:47 ` Jay
2008-09-18 15:23 ` Re[2]: " Paul-Kenji Cahier
0 siblings, 1 reply; 10+ messages in thread
From: Jay @ 2008-09-18 11:47 UTC (permalink / raw)
To: pkc, cygwin
> --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/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re[2]: Slow fork issue - Win x64
2008-09-18 11:47 ` Slow fork issue - Win x64 Jay
@ 2008-09-18 15:23 ` Paul-Kenji Cahier
2009-01-20 13:51 ` prashantv
0 siblings, 1 reply; 10+ messages in thread
From: Paul-Kenji Cahier @ 2008-09-18 15:23 UTC (permalink / raw)
To: Jay, cygwin
> but maybe merely bringing up AMD64 up to the speed of x86 would suffice.
I think that that would be already a great progress... I see no reason why amd64
windows' would be so much slower.
Another test on a vista 64 showed speeds around 7-8.
If anyone has any idea what to do to speed up up to the 32bit os' speed, I'd
be glad to hear about it.
Thanks,
Paul
--
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re[2]: Slow fork issue - Win x64
2008-09-18 15:23 ` Re[2]: " Paul-Kenji Cahier
@ 2009-01-20 13:51 ` prashantv
2010-02-16 12:19 ` Jarkko Häkkinen
0 siblings, 1 reply; 10+ messages in thread
From: prashantv @ 2009-01-20 13:51 UTC (permalink / raw)
To: cygwin
My speeds are even slower than those posted:
Prashant@HOME [~]
$ while (true); do date; done | uniq -c
1 Tue Jan 20 22:25:50 AUSEDT 2009
1 Tue Jan 20 22:25:51 AUSEDT 2009
2 Tue Jan 20 22:25:52 AUSEDT 2009
1 Tue Jan 20 22:25:53 AUSEDT 2009
2 Tue Jan 20 22:25:54 AUSEDT 2009
2 Tue Jan 20 22:25:55 AUSEDT 2009
1 Tue Jan 20 22:25:56 AUSEDT 2009
3 Tue Jan 20 22:25:57 AUSEDT 2009
1 Tue Jan 20 22:25:58 AUSEDT 2009
2 Tue Jan 20 22:25:59 AUSEDT 2009
2 Tue Jan 20 22:26:00 AUSEDT 2009
2 Tue Jan 20 22:26:01 AUSEDT 2009
I am running cygwin 1.5.25, Windows 2008 x64 on a Intel Core 2 @ 2.13ghz.
One CPU is maxed to 100% when forking. This speed explained why opening bash
took as long as 10 seconds, and I wanted to find out why it was so slow.
Is it possible to profile the implementation easily?
--
View this message in context: http://www.nabble.com/Slow-fork-issue---Win-x64-tp19538601p21561482.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Re[2]: Slow fork issue - Win x64
2009-01-20 13:51 ` prashantv
@ 2010-02-16 12:19 ` Jarkko Häkkinen
2010-02-18 0:15 ` Cyrille Lefevre
2010-10-10 19:38 ` Re[2]: " Nicole Hamilton
0 siblings, 2 replies; 10+ messages in thread
From: Jarkko Häkkinen @ 2010-02-16 12:19 UTC (permalink / raw)
To: cygwin
I'm getting rather similar results on my Cygwin 1.7.1, Windows 7 as evidenced
by the figures below. Upgraded from a dual core Windows XP to a quad core i7
Windows 7 causing my cygwin performance to plummet. Even the bash
auto-completion is so annoyingly sluggish that it makes the shell virtually
unusable.
For me, there's no choice between whether or not to make the transition from
XP to 7 as we're using the latest DirectX technology. Hope somebody will
figure this out.
[13:41:50 ~]$ while (true); do date; done | uniq -c
5 Tue Feb 16 14:00:09 FLEST 2010
7 Tue Feb 16 14:00:10 FLEST 2010
9 Tue Feb 16 14:00:11 FLEST 2010
9 Tue Feb 16 14:00:12 FLEST 2010
9 Tue Feb 16 14:00:13 FLEST 2010
9 Tue Feb 16 14:00:14 FLEST 2010
9 Tue Feb 16 14:00:15 FLEST 2010
9 Tue Feb 16 14:00:16 FLEST 2010
6 Tue Feb 16 14:00:17 FLEST 2010
5 Tue Feb 16 14:00:18 FLEST 2010
9 Tue Feb 16 14:00:19 FLEST 2010
prashantv wrote:
>
> My speeds are even slower than those posted:
>
> Prashant@HOME [~]
> $ while (true); do date; done | uniq -c
> 1 Tue Jan 20 22:25:50 AUSEDT 2009
> 1 Tue Jan 20 22:25:51 AUSEDT 2009
> 2 Tue Jan 20 22:25:52 AUSEDT 2009
> 1 Tue Jan 20 22:25:53 AUSEDT 2009
> 2 Tue Jan 20 22:25:54 AUSEDT 2009
> 2 Tue Jan 20 22:25:55 AUSEDT 2009
> 1 Tue Jan 20 22:25:56 AUSEDT 2009
> 3 Tue Jan 20 22:25:57 AUSEDT 2009
> 1 Tue Jan 20 22:25:58 AUSEDT 2009
> 2 Tue Jan 20 22:25:59 AUSEDT 2009
> 2 Tue Jan 20 22:26:00 AUSEDT 2009
> 2 Tue Jan 20 22:26:01 AUSEDT 2009
>
> I am running cygwin 1.5.25, Windows 2008 x64 on a Intel Core 2 @ 2.13ghz.
> One CPU is maxed to 100% when forking. This speed explained why opening
> bash took as long as 10 seconds, and I wanted to find out why it was so
> slow.
>
> Is it possible to profile the implementation easily?
>
--
View this message in context: http://old.nabble.com/Slow-fork-issue---Win-x64-tp19538601p27607447.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Slow fork issue - Win x64
2010-02-16 12:19 ` Jarkko Häkkinen
@ 2010-02-18 0:15 ` Cyrille Lefevre
2010-02-18 21:20 ` Jarkko Häkkinen
2010-10-10 19:38 ` Re[2]: " Nicole Hamilton
1 sibling, 1 reply; 10+ messages in thread
From: Cyrille Lefevre @ 2010-02-18 0:15 UTC (permalink / raw)
To: cygwin
Jarkko Häkkinen a écrit :
>
> I'm getting rather similar results on my Cygwin 1.7.1, Windows 7 as evidenced
> by the figures below. Upgraded from a dual core Windows XP to a quad core i7
> Windows 7 causing my cygwin performance to plummet. Even the bash
> auto-completion is so annoyingly sluggish that it makes the shell virtually
> unusable.
>
> For me, there's no choice between whether or not to make the transition from
> XP to 7 as we're using the latest DirectX technology. Hope somebody will
> figure this out.
>
> [13:41:50 ~]$ while (true); do date; done | uniq -c
> 5 Tue Feb 16 14:00:09 FLEST 2010
> 7 Tue Feb 16 14:00:10 FLEST 2010
> 9 Tue Feb 16 14:00:11 FLEST 2010
> 9 Tue Feb 16 14:00:12 FLEST 2010
> 9 Tue Feb 16 14:00:13 FLEST 2010
> 9 Tue Feb 16 14:00:14 FLEST 2010
> 9 Tue Feb 16 14:00:15 FLEST 2010
> 9 Tue Feb 16 14:00:16 FLEST 2010
> 6 Tue Feb 16 14:00:17 FLEST 2010
> 5 Tue Feb 16 14:00:18 FLEST 2010
> 9 Tue Feb 16 14:00:19 FLEST 2010
>
>
>
> prashantv wrote:
>> My speeds are even slower than those posted:
>>
>> Prashant@HOME [~]
>> $ while (true); do date; done | uniq -c
>> 1 Tue Jan 20 22:25:50 AUSEDT 2009
>> 1 Tue Jan 20 22:25:51 AUSEDT 2009
>> 2 Tue Jan 20 22:25:52 AUSEDT 2009
>> 1 Tue Jan 20 22:25:53 AUSEDT 2009
>> 2 Tue Jan 20 22:25:54 AUSEDT 2009
>> 2 Tue Jan 20 22:25:55 AUSEDT 2009
>> 1 Tue Jan 20 22:25:56 AUSEDT 2009
>> 3 Tue Jan 20 22:25:57 AUSEDT 2009
>> 1 Tue Jan 20 22:25:58 AUSEDT 2009
>> 2 Tue Jan 20 22:25:59 AUSEDT 2009
>> 2 Tue Jan 20 22:26:00 AUSEDT 2009
>> 2 Tue Jan 20 22:26:01 AUSEDT 2009
>>
>> I am running cygwin 1.5.25, Windows 2008 x64 on a Intel Core 2 @ 2.13ghz.
>> One CPU is maxed to 100% when forking. This speed explained why opening
>> bash took as long as 10 seconds, and I wanted to find out why it was so
>> slow.
>>
>> Is it possible to profile the implementation easily?
bash is not an efficient shell :
while : ; do date; done | uniq -c
5 Thu Feb 18 01:03:30 2010
8 Thu Feb 18 01:03:31 2010
8 Thu Feb 18 01:03:32 2010
9 Thu Feb 18 01:03:33 2010
8 Thu Feb 18 01:03:34 2010
9 Thu Feb 18 01:03:35 2010
8 Thu Feb 18 01:03:36 2010
5 Thu Feb 18 01:03:37 2010
let's try pdksh (well, not really more efficient) :
7 Thu Feb 18 01:03:38 2010
9 Thu Feb 18 01:03:39 2010
8 Thu Feb 18 01:03:40 2010
8 Thu Feb 18 01:03:41 2010
8 Thu Feb 18 01:03:42 2010
9 Thu Feb 18 01:03:43 2010
8 Thu Feb 18 01:03:44 2010
8 Thu Feb 18 01:03:45 2010
8 Thu Feb 18 01:03:46 2010
7 Thu Feb 18 01:03:47 2010
and ksh 93 :
8 Thu Feb 18 01:03:59 2010
7 Thu Feb 18 01:04:00 2010
12 Thu Feb 18 01:04:01 2010
12 Thu Feb 18 01:04:02 2010
12 Thu Feb 18 01:04:03 2010
12 Thu Feb 18 01:04:04 2010
12 Thu Feb 18 01:04:05 2010
12 Thu Feb 18 01:04:06 2010
12 Thu Feb 18 01:04:07 2010
12 Thu Feb 18 01:04:08 2010
ksh88 is not so bad :
7 Thu Feb 18 01:06:47 2010
6 Thu Feb 18 01:06:48 2010
10 Thu Feb 18 01:06:49 2010
9 Thu Feb 18 01:06:50 2010
9 Thu Feb 18 01:06:51 2010
10 Thu Feb 18 01:06:52 2010
9 Thu Feb 18 01:06:53 2010
9 Thu Feb 18 01:06:54 2010
8 Thu Feb 18 01:06:55 2010
9 Thu Feb 18 01:06:56 2010
tests realised under cygwin 1.7 on a Q6600 in 32 bit mode (around 30% of
cpu usage)
Cordialement,
Cyrille Lefevre
--
mailto:Cyrille.Lefevre-lists@laposte.net
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Slow fork issue - Win x64
2010-02-18 0:15 ` Cyrille Lefevre
@ 2010-02-18 21:20 ` Jarkko Häkkinen
0 siblings, 0 replies; 10+ messages in thread
From: Jarkko Häkkinen @ 2010-02-18 21:20 UTC (permalink / raw)
To: cygwin
Your results notwithstanding, my performance (if you want to call looping
'date's that) went down five-fold from what it was on XP 32-bit and
corresponds to the figures posted at the beginning of the thread. And as to
the bash not being "efficient shell", that may very well be but I think it
would be naive to think that a fellow developer does not notice changes in
his development environment as apparent as auto-completion or compilation --
routines repeated thousands of times over many years.
Obviously, there could be something else wrong in my setup as well, but I
did ran similar tests through the native command shell and been timing my
compilation times on MSVC. Everything is lightning-fast in comparison to my
old dev env -- just not cygwin.
-J
Cyrille Lefevre wrote:
>
>
> bash is not an efficient shell :
>
> while : ; do date; done | uniq -c
>
> 5 Thu Feb 18 01:03:30 2010
> 8 Thu Feb 18 01:03:31 2010
> 8 Thu Feb 18 01:03:32 2010
> 9 Thu Feb 18 01:03:33 2010
> 8 Thu Feb 18 01:03:34 2010
> 9 Thu Feb 18 01:03:35 2010
> 8 Thu Feb 18 01:03:36 2010
> 5 Thu Feb 18 01:03:37 2010
>
> let's try pdksh (well, not really more efficient) :
>
> 7 Thu Feb 18 01:03:38 2010
> 9 Thu Feb 18 01:03:39 2010
> 8 Thu Feb 18 01:03:40 2010
> 8 Thu Feb 18 01:03:41 2010
> 8 Thu Feb 18 01:03:42 2010
> 9 Thu Feb 18 01:03:43 2010
> 8 Thu Feb 18 01:03:44 2010
> 8 Thu Feb 18 01:03:45 2010
> 8 Thu Feb 18 01:03:46 2010
> 7 Thu Feb 18 01:03:47 2010
>
> and ksh 93 :
>
> 8 Thu Feb 18 01:03:59 2010
> 7 Thu Feb 18 01:04:00 2010
> 12 Thu Feb 18 01:04:01 2010
> 12 Thu Feb 18 01:04:02 2010
> 12 Thu Feb 18 01:04:03 2010
> 12 Thu Feb 18 01:04:04 2010
> 12 Thu Feb 18 01:04:05 2010
> 12 Thu Feb 18 01:04:06 2010
> 12 Thu Feb 18 01:04:07 2010
> 12 Thu Feb 18 01:04:08 2010
>
> ksh88 is not so bad :
>
> 7 Thu Feb 18 01:06:47 2010
> 6 Thu Feb 18 01:06:48 2010
> 10 Thu Feb 18 01:06:49 2010
> 9 Thu Feb 18 01:06:50 2010
> 9 Thu Feb 18 01:06:51 2010
> 10 Thu Feb 18 01:06:52 2010
> 9 Thu Feb 18 01:06:53 2010
> 9 Thu Feb 18 01:06:54 2010
> 8 Thu Feb 18 01:06:55 2010
> 9 Thu Feb 18 01:06:56 2010
>
> tests realised under cygwin 1.7 on a Q6600 in 32 bit mode (around 30% of
> cpu usage)
>
> Cordialement,
>
> Cyrille Lefevre
> --
> mailto:Cyrille.Lefevre-lists@laposte.net
>
>
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
>
--
View this message in context: http://old.nabble.com/Slow-fork-issue---Win-x64-tp19538601p27645832.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re[2]: Slow fork issue - Win x64
2010-02-16 12:19 ` Jarkko Häkkinen
2010-02-18 0:15 ` Cyrille Lefevre
@ 2010-10-10 19:38 ` Nicole Hamilton
2010-10-11 18:16 ` Reini Urban
1 sibling, 1 reply; 10+ messages in thread
From: Nicole Hamilton @ 2010-10-10 19:38 UTC (permalink / raw)
To: cygwin
Jarkko Häkkinen wrote:
>
> I'm getting rather similar results on my Cygwin 1.7.1, Windows 7 as
> evidenced by the figures below.
> :
>
> [13:41:50 ~]$ while (true); do date; done | uniq -c
> 5 Tue Feb 16 14:00:09 FLEST 2010
> 7 Tue Feb 16 14:00:10 FLEST 2010
> 9 Tue Feb 16 14:00:11 FLEST 2010
> 9 Tue Feb 16 14:00:12 FLEST 2010
>
Oh, my. Here's what I get with 64-bit Hamilton C shell on Windows 7 on a
2.67GHz Core i7:
10 C% date +"%a %b %d %H:%M:%S %Z %Y"
Sun Oct 10 12:03:31 PDT 2010
11 C% while (1) !!; end | uniq -c
while ( 1 ) date +"%a %b %d %H:%M:%S %Z %Y" ; end | uniq -c
164 Sun Oct 10 12:03:51 PDT 2010
170 Sun Oct 10 12:03:52 PDT 2010
169 Sun Oct 10 12:03:53 PDT 2010
169 Sun Oct 10 12:03:54 PDT 2010
Here's what I get on a MacBook with a 2.4GHz Core 2 Duo, again running
64-bit code on Win7:
8 C% while ( 1 ) date +"%a %b %d %H:%M:%S %Z %Y" ; end | uniq -c
17 Sun Oct 10 12:17:21 PDT 2010
84 Sun Oct 10 12:17:22 PDT 2010
77 Sun Oct 10 12:17:23 PDT 2010
78 Sun Oct 10 12:17:24 PDT 2010
But this is running native, using threads instead of a fork emulation.
Regards,
Nicole
Full disclosure: I wrote the Hamilton C shell.
--
View this message in context: http://old.nabble.com/Slow-fork-issue---Win-x64-tp19538601p29929206.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re[2]: Slow fork issue - Win x64
2010-10-10 19:38 ` Re[2]: " Nicole Hamilton
@ 2010-10-11 18:16 ` Reini Urban
2010-10-11 19:11 ` Nicole Hamilton
0 siblings, 1 reply; 10+ messages in thread
From: Reini Urban @ 2010-10-11 18:16 UTC (permalink / raw)
To: cygwin
2010/10/10 Nicole Hamilton:
> Jarkko Häkkinen wrote:
>> I'm getting rather similar results on my Cygwin 1.7.1, Windows 7 as
>> evidenced by the figures below.
>>
>> [13:41:50 ~]$ while (true); do date; done | uniq -c
>> 5 Tue Feb 16 14:00:09 FLEST 2010
>> 7 Tue Feb 16 14:00:10 FLEST 2010
>> 9 Tue Feb 16 14:00:11 FLEST 2010
>> 9 Tue Feb 16 14:00:12 FLEST 2010
>
> Oh, my. Here's what I get with 64-bit Hamilton C shell on Windows 7 on a
> 2.67GHz Core i7:
>
> 10 C% date +"%a %b %d %H:%M:%S %Z %Y"
> Sun Oct 10 12:03:31 PDT 2010
> 11 C% while (1) !!; end | uniq -c
> while ( 1 ) date +"%a %b %d %H:%M:%S %Z %Y" ; end | uniq -c
> 164 Sun Oct 10 12:03:51 PDT 2010
> 170 Sun Oct 10 12:03:52 PDT 2010
> 169 Sun Oct 10 12:03:53 PDT 2010
> 169 Sun Oct 10 12:03:54 PDT 2010
>
> Here's what I get on a MacBook with a 2.4GHz Core 2 Duo, again running
> 64-bit code on Win7:
>
> 8 C% while ( 1 ) date +"%a %b %d %H:%M:%S %Z %Y" ; end | uniq -c
> 17 Sun Oct 10 12:17:21 PDT 2010
> 84 Sun Oct 10 12:17:22 PDT 2010
> 77 Sun Oct 10 12:17:23 PDT 2010
> 78 Sun Oct 10 12:17:24 PDT 2010
>
> But this is running native, using threads instead of a fork emulation.
And native linux 64-bit bash has these:
rurban@deblap:~$ while (true); do date; done | uniq -c
228 Mon Okt 11 20:12:51 CEST 2010
250 Mon Okt 11 20:12:52 CEST 2010
221 Mon Okt 11 20:12:53 CEST 2010
200 Mon Okt 11 20:12:54 CEST 2010
183 Mon Okt 11 20:12:55 CEST 2010
179 Mon Okt 11 20:12:56 CEST 2010
165 Mon Okt 11 20:12:57 CEST 2010
150 Mon Okt 11 20:12:58 CEST 2010
146 Mon Okt 11 20:12:59 CEST 2010
We know bash is slow, so
rurban@deblap:~$ dash
$ while (true); do date; done | uniq -c
232 Mon Okt 11 20:14:51 CEST 2010
508 Mon Okt 11 20:14:52 CEST 2010
508 Mon Okt 11 20:14:53 CEST 2010
510 Mon Okt 11 20:14:54 CEST 2010
507 Mon Okt 11 20:14:55 CEST 2010
511 Mon Okt 11 20:14:56 CEST 2010
502 Mon Okt 11 20:14:57 CEST 2010
508 Mon Okt 11 20:14:58 CEST 2010
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Re[2]: Slow fork issue - Win x64
2010-10-11 18:16 ` Reini Urban
@ 2010-10-11 19:11 ` Nicole Hamilton
0 siblings, 0 replies; 10+ messages in thread
From: Nicole Hamilton @ 2010-10-11 19:11 UTC (permalink / raw)
To: cygwin
Reini Urban wrote:
>
> And native linux 64-bit bash has these:
>
> rurban@deblap:~$ while (true); do date; done | uniq -c
> 228 Mon Okt 11 20:12:51 CEST 2010
> 250 Mon Okt 11 20:12:52 CEST 2010
> 221 Mon Okt 11 20:12:53 CEST 2010
> 200 Mon Okt 11 20:12:54 CEST 2010
> 183 Mon Okt 11 20:12:55 CEST 2010
>
True. On the same MacBook where I get counts of about 80 with my csh under
Win7, I get counts of about 150 to 200 (sometimes higher) with bash under
OSX.
Threads are very cheap under Windows but process creation is quite a bit
more expensive than under Unix or Linux. This is part of why you're getting
hammered so badly emulating fork (in addition to obvious problems of not
having access to the page tables, which will get worse with the larger
images of 64-bit applications.) Your own application code runs at whatever
the processor speed is. But the OS underneath will reward or penalize you
with its own performance characteristics, depending on how you use it.
Regards,
Nicole
--
View this message in context: http://old.nabble.com/Slow-fork-issue---Win-x64-tp19538601p29937002.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 10+ messages in thread
* Slow fork issue - Win x64
@ 2008-09-18 3:23 Paul-Kenji Cahier
0 siblings, 0 replies; 10+ messages in thread
From: Paul-Kenji Cahier @ 2008-09-18 3:23 UTC (permalink / raw)
To: cygwin
Hello,
I have been noticing extreme slowdowns in vista/2k8 64 with latest cygwin 1.5.
Fresh installation, no antivirus.
The command used to test speed is:
while (true); do date; done | uniq -c
On windows 2008 64bit:
11 Wed Sep 17 20:35:22 RDT 2008
11 Wed Sep 17 20:35:23 RDT 2008
12 Wed Sep 17 20:35:24 RDT 2008
11 Wed Sep 17 20:35:25 RDT 2008
12 Wed Sep 17 20:35:26 RDT 2008
11 Wed Sep 17 20:35:27 RDT 2008
12 Wed Sep 17 20:35:28 RDT 2008
11 Wed Sep 17 20:35:29 RDT 2008
11 Wed Sep 17 20:35:30 RDT 2008
On windows XP SP3 32bit:
51 Wed Sep 17 20:35:42 2008
50 Wed Sep 17 20:35:43 2008
50 Wed Sep 17 20:35:44 2008
51 Wed Sep 17 20:35:45 2008
50 Wed Sep 17 20:35:46 2008
51 Wed Sep 17 20:35:47 2008
48 Wed Sep 17 20:35:48 2008
50 Wed Sep 17 20:35:49 2008
50 Wed Sep 17 20:35:50 2008
I of course wont compare to linux since the situation is quite different(and cygwin's fork
has a lot more work to do)
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.
But then I ran the following test:
Running 200 times the 32bit cmd.exe /C exit from cygwin and from a normal 32bit windows cmd.
To my great surprise cygwin took 14seconds, while cmd took 2.5seconds.
The only difference I can see between the two is that cygwin's fork does more work...
But should it really be such a big difference?
Thanks for any hints,
--
Best regards,
Paul-Kenji mailto:pkc@F1-Photo.com
--
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/
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-10-11 19:11 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1221716111.21095.ezmlm@cygwin.com>
2008-09-18 11:47 ` Slow fork issue - Win x64 Jay
2008-09-18 15:23 ` Re[2]: " Paul-Kenji Cahier
2009-01-20 13:51 ` prashantv
2010-02-16 12:19 ` Jarkko Häkkinen
2010-02-18 0:15 ` Cyrille Lefevre
2010-02-18 21:20 ` Jarkko Häkkinen
2010-10-10 19:38 ` Re[2]: " Nicole Hamilton
2010-10-11 18:16 ` Reini Urban
2010-10-11 19:11 ` Nicole Hamilton
2008-09-18 3:23 Paul-Kenji Cahier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).