vfork() (was Re: RS6000 questions/comments)

[John F Haugh II]

In article <DERAADT.91Jun30030305 at fsa.cpsc.ucalgary.ca> deraadt at cpsc.ucalgary.ca (Theo de Raadt) writes:
>I'll bite and shove a vfork() in there instead of fork(). Here are
>times for a Sun4/490, sunos4.1.1.
>
> fork()      101.1 real         5.6 user        90.2 sys	  99  fork/sec
>vfork()        9.7 real         0.5 user         6.5 sys	1030 vfork/sec
>
>I suggest those who say that vfork() is not needed anymore try this test
>on their machine.

No, all you've managed to prove is that you have a future as a marketing
strategist ;-)

This test is pretty meaningless when vfork() is used since vfork() does
nothing.  For a really good time, try this one -

-- exec.c --
main ()
{
	int	i;

	for (i = 0;i < 1000;i++)
		if (FORK () == 0)
			execl ("./exit", "exit", 0);
		else
			while (wait (0) != -1)
				;
}
-- exit.c --
main ()
{
	_exit (0);
}
--

What we are trying to measure is the amount of time that it takes to
execute a =different= new process.  The "forks per second" rate gives
the maximum number of new processes per second.  Since vfork does
little or nothing, you need to measure "vfork/execs per second".  My
prediction is that you will find the difference isn't that impressive.
The exec() will cause a new address space to be cobbled up, while a
COW fork() will just dump the unscribbled on pages and not waste any
time.  The blindingly quick vfork() should lose its advantage to the
work that exec() must do anyway.

To run your little test, compile "fork.c" with

% cc -o vfork -DFORK=vfork exec.c
% cc -o fork -DFORK=fork exec.c
% cc -o exit exit.c

% timex ./fork
execution complete, exit code = 1

real	      1:11.24
user	         0.11
sys	      1:07.65
% calc 1000 / 71.24
	 14.03705783267827

and time both ./fork and ./vfork with timex as before.  I ran the
test here and got about 14 per second, which isn't all that awful.

And since a retraction is probably in order regarding the v3
fork/exec speed, I'll have to admit that the numbers I saw were
from before GA.  I was writing a stress test for a collection of
system calls I had written and couldn't figure out what the bottle
neck was.  It turned out to be slow fork/exec performance.  My
guess is that someone else noticed this and fixed it, or else
that debugging (or tracing, or ...) was turned off prior to GA
and the system picked up.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn