Can I speed up cygwin's fork?

Question

I came across a post discussing the speed of forking in Cygwin, giving an expected 'fork rate' in Windows XP of around 30-50 per-second (link)

I've got a Core 2 duo (1.79GHz) which I would expect to get comparable results, but it's only managing around 8 forks per second (and sometimes a lot fewer):

$ while (true); do date --utc; done | uniq -c
      5 Wed Apr 21 12:38:10 UTC 2010
      6 Wed Apr 21 12:38:11 UTC 2010
      1 Wed Apr 21 12:38:12 UTC 2010
      1 Wed Apr 21 12:38:13 UTC 2010
      8 Wed Apr 21 12:38:14 UTC 2010
      8 Wed Apr 21 12:38:15 UTC 2010
      6 Wed Apr 21 12:38:16 UTC 2010
      1 Wed Apr 21 12:38:18 UTC 2010
      9 Wed Apr 21 12:38:19 UTC 2010

Can you suggest anything I might be able to do to speed things up? This machine acts a lot slower in Cygwin than others I've used before which actually were a lot slower.

Update

Let my justify my question: I don't believe that having a faster fork will magically make my life better, but I believe that this benchmark is a good proxy for the performance issues I'm seeing in bash due to normal use of external executables to calculate values. I find I get a noticeable speed up on Cygwin by going through my shell start up scripts and bash-completion and trying to replace external commands with internal ones; on Linux this isn't an issue. Often, though, this isn't possible, and my PC is currently taking ~14s to start a shell with a warm cache and no load.

Answer 1

This has nothing to do with fork being slow.

I've seen cygwin run dog slow when the windows "home" directory was on a network drive. Every single command would search there for binaries slowing things down tremendously.

see if

while (true); do /bin/date --utc; done | uniq -c

is faster, if so, that is probably your problem

otherwise try running bash via strace/ltrace (if they even work on cygwin) and see what it is doing when it takes 1 second to execute date.

Answer 2

I'm afraid there is nothing much you can do about this.

Windows does not have a native fork() syscall so Cygwin has to emulate this. The implementation of this emulation is very inefficient though. (See Cygwin FAQ)

MSYS2, which is often used in applications where one wants a possibly fully featured Linux-like command line environment on windows, is based on Cygwin, which is why it's also affected by this.

It's actually so bad, that a fork() on Windows is at least one order of magnitude slower than on Linux

msys2bash-windows-box$ time { date; }
Sa, 24. Feb 2018 16:51:44

real    0m0,046s
user    0m0,000s
sys     0m0,000s

msys2bash-windows-box$ while (true); do /bin/date --utc; done | uniq -c
     13 Sa, 24. Feb 2018 15:57:18
     17 Sa, 24. Feb 2018 15:57:19
     16 Sa, 24. Feb 2018 15:57:20


bash-linux-box$ time { date; }
Sat Feb 24 15:51:54 UTC 2018

real    0m0.002s
user    0m0.000s
sys     0m0.000s

bash-linux-box$ while (true); do date --utc; done | uniq -c
    211 Sat Feb 24 15:56:35 UTC 2018
    286 Sat Feb 24 15:56:36 UTC 2018
    260 Sat Feb 24 15:56:37 UTC 2018

The above example shows the difference between an i5-2500k @ 4GHz, 32GiB RAM Windows 10 Pro box vs. a feeble one-core, 1GiB RAM VPS

Answer 3

You're not seeing forks; you're seeing fork, exec, system call to read time of day clock, format and convert the output. Not to mention whatever else is time sharing in parallel.

On what basis do you say the other machines "actually were slower"? There are a lot of things that contribute to a computer's actual speed and to the user's perception of the computer speed. What sort of things are you doing where forks/sec is a good measure of performance? What's the memory speed, architecture and amount? Disk I/O speed and buffering?

Which do you think will do more forks/sec: a Core i7 running Vista with 512MB of RAM or a Celeron running a minimal Linux with 2 GB?