🚀 go-pugleaf

[someone wrote a replacement for "sum", called "fastsum" that uses mmap().]

You are comparing your efficient "fastsum" that happens to use mmap()
against a sluggardly "sum" that happens to use read().
(Actually it uses getchar(), which calls _filbuf(),
maybe _filbuf() uses mmap()?!)

The following would be a more appropriate test:
Change your fastsum routine so that instead of mmap()ing
a megabyte at a time, it does a read() of a megabyte at a time. 
Compare the mmap() and read() versions of this program.
I suspect you will find they take about the same amount of time.

On a Sparcstation 1, try timing "cp" vs. the following program:

    main()
    {
	    char bfr[8192];
	    register int n;

	    while ((n = read(0, bfr, sizeof(bfr))) > 0)
		    write(1, bfr, n);
    }

I did "/bin/time cp /vmunix /tmp/x"
and "/bin/time a.out < /vmunix /tmp/x" several times.
The results were essentially identical.
(I did not experiment with buffer sizes, I suspect 16k would be faster.)

There is no inherent reason that read() should be slower
than mmap() for sequential I/O, since read() is doing precisely
what is wanted.  Indeed read() should be faster since
it is conceptually simpler.

Note that read() can be implemented with memory mapping, in some cases:
it could map the address of "bfr" to a copy-on-modify kernel page.
That would eliminate user <==> kernel data copying.
I can imagine an improved read/write and stdio resulting
from this sort of thing.  But somehow I think mmap() is getting
the intellectual juice these days.

As others have pointed out, read() and write() are generally useful
on streams, and mmap() is not.
(The SunOS "cp" command falls back to read/write if mmap() fails.
But since read/write is as fast as mmap(),
why bother with mmap() in the first place?!)

So what is mmap() good for?  Plenty.
But it is NOT a replacement for read/write.
	Tom Truscott