Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!nuchat!steve From: steve@nuchat.UUCP (Steve Nuchia) Newsgroups: comp.unix.internals Subject: Re: UNIX semantics do permit full support for asynchronous I/O Message-ID: <27820@nuchat.UUCP> Date: 2 Sep 90 18:06:04 GMT References: <60345@lanl.gov> <27619@nuchat.UUCP> <1990Aug30.222226.20866@cbnewsm.att.com> <29290:Aug3120:10:5590@kramden.acf.nyu.edu> Reply-To: steve@nuchat.UUCP (Steve Nuchia) Distribution: usa Organization: Houston Public Access Lines: 24 In article bzs@world.std.com (Barry Shein) writes: >Do there exist any benchmark or other test results which indicate that >adding asynch i/o to unix actually yields a performance improvement? There is little question that it can dramatically speed up selected applications. Applications, mostly in the backup arena (afio, ddd) get substancially improved throughput even using really stupid mechanisms. In afio's case the mechanism is to do a fork for every write, and it is still a lot faster than running without the feature enabled. One poster mentioned as fact that the point behind asynch I/O was to overlap computation and I/O. At least in the backup arena the point is to overlap some I/O (tape) with other I/O (disk). In this case it should be clear that the overall system throughput is not damaged by the presence of an application using (well-implemented) asynch I/O if the remaining job mix is CPU intensive. Reference: Winter 88 Usenix, "A Faster UNIX Dump Program", Jeff Polk and Rob Kolstad (both then of CONVEX). -- Steve Nuchia South Coast Computing Services (713) 964-2462 "To learn which questions are unanswerable, and _not_to_answer_them; this skill is most needful in times of stress and darkness." Ursula LeGuin, _The_Left_Hand_of_Darkness_