Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!stan!salgado!dworkin
From: dworkin@salgado.Solbourne.COM (Dieter Muller)
Newsgroups: comp.arch
Subject: Re: mmap() vs. read() (Was: Re: the Multics from the black lagoon :-))
Message-ID: <1990Feb14.022338.13721@Solbourne.COM>
Date: 14 Feb 90 02:23:38 GMT
References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <1990Feb12.053616.11455@Solbourne.COM> <3556@rti.UUCP> <10468@alice.UUCP> <131682@sun.Eng.Sun.COM> <1990Feb13.003010.23356@utzoo.uucp> <131754@sun.Eng.Sun.COM>
Sender: news@Solbourne.COM
Reply-To: dworkin@salgado.UUCP (Dieter Muller)
Organization: Solbourne Computer, Inc.
Lines: 28

In article <131682@sun.Eng.Sun.COM> gingell@sun.UUCP (Rob Gingell) writes:
>... At the very least, the read() version will be slower
>than the mmap() version by the amount of time required to effect the
>copies from kernel to program buffers...

A few days ago, I posted the results of sum versus fastsum (which
used mmap).  Someone rightly pointed out that the former was going
through lots of grotty stdio code.  Well, I just took fastsum and
(effectively) replaced the mmap calls with read calls.

	salgado {47} time fastsum /image/os/4.0C/upgrade/USR.tar
	36.1u 11.8s 0:53 89% 0+640k 2+0io 3614pf+0w
	salgado {48} time ./gerbil /image/os/4.0C/upgrade/USR.tar
	35.2u 14.0s 1:18 63% 0+1136k 3601+0io 3645pf+0w

User time is a little less, but system time is significantly greater.
I suspect most of the difference is in copying the data around in the
kernel.  The data buffer, btw, was declared global and static, so
alignment should be the best you can expect w/o hand-tuning things.

The data file and general conditions were the same as in my previous
posting.

	Dworkin
--
Martha, the platypus is into the rutabagas again!
boulder!stan!dworkin  dworkin%stan@boulder.colorado.edu  dworkin@solbourne.com
Flamer's Hotline: (303) 678-4624 (1000 - 1800 Mountain Time)