🚀 go-pugleaf

In article <2106@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>
>  In VMS the performance gain [from the mmap()-equivalent] was about
>30%, and the program was smaller as well. [...]
>
>  Perhaps someone who has used the BSD mapping (is is mmap()?) could
>give us some actual timings on unix, since my experience is with other
>systems. Is mapping in V.4???

I've had to do a lot of file checksumming in the last few months.  Since
this takes approximately forever on a 30+ MB file, I finally sat down
and merged the mmap() code out of cp(1) and the checksumming code out
of sum(1).

On a single-CPU Series4 Solbourne system:

    salgado {44} time fastsum /image/os/4.0C/upgrade/USR.tar > /dev/null
    37.3u 11.4s 0:55 87% 0+648k 4+0io 3612pf+0w

    salgado {45} time sum /image/os/4.0C/upgrade/USR.tar > /dev/null
    65.4u 17.0s 1:28 92% 0+184k 3533+0io 3554pf+0w

    salgado {46} ls -l /image/os/4.0C/upgrade/USR.tar
    -rw-rw-r--  1 root     29458432 Jan 12 16:15 /image/os/4.0C/upgrade/USR.tar

I did fastsum first, so there wouldn't be any buffered blocks left over
from the `real' sum run (physical memory on this system is 32 MB, so
it is possible, though unlikely, with an Emacs running...).

The chunk size (amount mapped at a time) is 1 MB.  This is the same
chunk size used by cp().  Since I seem to be CPU-bound at this point,
there's no advantage to making it larger.

Also, the system load average was baselined at 0.45, during fastsum it
peaked at 0.88, and during sum, it peaked at 1.2.  The significance?
You tell me.

	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)