[ un-cc'd gnats-bugs, since this is mostly irrelevant to the PR. ]

woods@weird.com (Greg A. Woods) writes:
> I can see how mmap() can be more efficient in terms of CPU resources and
> memory throughput (buffers never have to be copied to user-space if the
> kernel does the mapping and page-faulting carefully) but in the case of
> a program like cmp there's almost always going to be lots of time spent
> waiting for disks to spin (and I suspect the ratio of secondary storage
> access speeds and CPU/RAM speeds is fairly constant across all major
> classifications of machines too).

so the choice is:

(a) spend time blocked (not utilizing the CPU), or

(b) spend time blocked (not utilizing the CPU) and then chew a bunch
of CPU and memory bandwidth copying data?


> What's even more silly is that if indeed mmap() is a much more efficient
> way to access files (at least those smaller than SIZE_T_MAX :-) then
> wouldn't it be a heck of a lot smarter and simpler to write this code
> once in a stdio-like library (pkgsrc/devel/sfio already does this, for
> example) and then keep all the applications dead simple and straight
> forward?

it would probably be a good idea; how about you go and do it?  8-)


> In fact now that SFIO is really freeware (well no fee for redistribution
> is permitted) perhaps it should be considered directly.

"go read the license."  it may be freeware, but for the majority of
purposes (in my opinion) the license is such that it may as well not
be.

If AT&T wants people to use their open-source-ish software, they're
gonna have to do something more sane with the licensing.  The good
thing is, at least some people there -- including at least one lawyer
-- understands that.



cgd