Shell Scripts v. Command Options

[John F Haugh II]

In article <19394:Jan1917:08:2691 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <18959 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
>> Had you looked at the test data you would see that the CPU time is
>> actually spent in the kernel executing code.
>
>Apparently the system is idle in your tests; many if not most schedulers
>will add disk wait time to the system time of the current process.

There was no disk wait time, nor did there need to be.  You are missing
something very crucial here - if the system were idle and I hadn't
consumed all available disk buffers, then there would be no physical I/O
anyway since the blocks come straight out of the buffer pool.  On the
other hand, if the scheduler DID charge for disk-wait time, you would
have the sum of all executing commands system time higher than the total
wall clock time and that is just plain wrong.  Normally the "current
process" is the system itself or the "idle" process.  But in most cases
I've seen since v7, there is no accounting for the time - no process
see the ticks in their accounting structure.  You can verify this with
the "crash" command.  Finally, there was no need for disk I/O at all
since I had not run out of physical memory and did not need to page out
or read from the file system - I executed no new commands in the original
fork/(exit|wait) scenario.  Besides, I'm sitting right next to the drive
which make an incredible racket, so I would have heard them go
clickity-click-clack if there were any I/O.

A counter-proof would be to execute multiple copies of that test at
the same time.  If the total time remained constant for increasing
numbers of simultanous executions of the test case, you would be proven
correct.  However, I have done exactly this test at past jobs and it
has demonstrated that the fork() call does not overlap time well.  It
really is just a very CPU intensive call.  People will point out that
it is very wasteful, and I agree - I also agree that fork() should be
fixed rather than avoided, but given that the vendors REFUSE to make
fork() faster, I don't see any real option but to avoid it.
--
Script is typescript, started Sat Jan 19 13:51:45 1991
rpp386-> cat fork.c
main ()
{
	int	i;

	for (i = 0;i < 100;i++)
		if (fork ())
			wait (0);
		else
			_exit (0);
}
rpp386-> cc -o fork fork.c
fork.c
rpp386-> timex ./fork
execution complete, exit code = 1

real	         1.31
user	         0.00
sys	         1.23
rpp386-> cat fork.sh
./fork &
./fork &
./fork &
./fork &
./fork &
wait
rpp386-> timex /bin/sh fork.sh
execution complete

real	         6.93
user	         0.05
sys	         6.36
rpp386-> 
Script done Sat Jan 19 13:52:24 1991
--
Doing the math,
% calc 6.93 / 5
	 1.386
% calc 6.36 / 5
	 1.272

Which you can see is pretty damned close to 1.31 and 1.23
in the first case.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh at rpp386.cactus.org
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."