Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stl!news
From: news@stl.stc.co.uk (News admin c/o dww)
Newsgroups: comp.arch
Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers)
Message-ID: <4033@stl.stc.co.uk>
Date: 13 Feb 91 21:16:38 GMT
References: <1991Feb4.210853.22139@odin.corp.sgi.com> <1652@hpwala.wal.hp.com> <409@bria> <13252@lanl.gov> <1991Feb4.154607.8606@ux1.cso.uiuc.edu> <1991Feb5.020456.1119@ux1.cso.uiuc.edu> <3177@crdos1.crd.ge.COM>
Organization: STC Technology Ltd., Harlow, Essex, GB
Lines: 30
From:tom@nw.stl.stc.co.uk
Reply-To:tom@nw.stl.stc.co.uk

In article <3177@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>UNIX writes usually overlap CPU, since the system buffers them. Async
>makes little difference in run time for an i/o bound job or a CPU bound
>job, it's only in the case where i/o and CPU time are roughly equal that
>a major improvement is seen.
>-- 
>bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
Might as well point out the several problems with this:
(i) buffering writes in the OS means I don't know when a transfer has
terminated.  That's a real pain if I'm trying to maintain some sort of
consistency and recoverability for the data.
(ii) buffering writes in the OS means an extra copy. Usually lots of extra
slave misses, waste cache space, etc, as well as waste store and bus bandwidth;
we can't always afford to throw away performance like this.
(iii) Async io can make enormous differences in run time for io bound jobs -
bd's conventional "wisdom" is an example of the rubbish that so-called software
architects have foisted off on an unsuspecting world as knowledge. It's simple,
really: if I am reading from 5 different discs, I can overlap the seek times,
search times, and even channel times if they are split over two or more
channels. Without asynch IO I can't get any of this overlap - the parallelism
between discs, between controllers, and between channels has been stolen from
me.  So async io gives me maybe a 5 times speed up fro this hypothetical 
five disc job, if it's io bound.
(iv)The speed up for cpu bound jobs may be less spectacular, but it's there;
if some elapsed time is critical, a 1% reduction may matter. The argument is
crazy anyway: BD is suggesting that because I'm CPU bound I can afford to use
synchronous IO and let the CPU stand idle while I wait for some macroscopic
mechanical events - chuck away some of precisely that resource I'm short of.

Tom Thomson