Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: the Multics from the black lagoon :-)
Message-ID: <1990Feb12.204658.18336@utzoo.uucp>
Organization: U of Toronto Zoology
References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> <2106@crdos1.crd.ge.COM>
Date: Mon, 12 Feb 90 20:46:58 GMT

In article <2106@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>  File mapping... replaces
>the runtime and kernel buffering scheme with the kernel page mechanism,
>which is often much faster.
>  In VMS the performance gain was about 30%...

I'm afraid my reaction to this is "what would the performance gain have
been if the same effort had been put into speeding up normal I/O"?
Modulo one or two requirements like alignment, if there is *any* real
performance difference with only one process involved, it means you
are comparing apples to oranges -- either the kernel I/O code has not
been optimized to exploit the MMU, or you are comparing an I/O version
which works (say) 512 bytes at a time to a mapped version that grabs
the whole file at once.  When only one process is involved, read() and
write() do everything that mmap() does, and there is no reason why they
should be any slower.

I agree that the situation is a bit messier when multiple processes are
involved... but interprocess communication is a different issue and a
much messier one anyway.
-- 
SVR4:  every feature you ever |     Henry Spencer at U of Toronto Zoology
wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu