Re: CRC in Ada?

[Jim Balter <jqb@netcom.com>]

Larry Kilgallen wrote:

> Why should finding a record with particular contents in the middle of
> a file take a long time?  There are books about how to write indexed
> file systems, but some operating systems skipped that part of what I
> am accustomed to relying upon.  I don't include that to start a
> feature war, but to introduce the next question:  How hard is it to
> get-character-from-file when the file has all that baggage used to
> find records with with particular contents ? DEC compilers run
> more slowly when fed such a file, because it is beyond the ability
> programmed into their map-it-into-memory trick.

How does one write a series of 3 megabyte text lines to a
record-oriented filesystem that was only designed with 16-bit record
lengths?

Putting record indexing into the filesystem is putting it at the wrong
level of abstraction.  Commercial databases are written on UNIX
systems by doing direct I/O to disk devices or partitions.  The OS
vendor cannot write an indexed system general enough to provide the
extremes of performance needed by such databases, which comes back to
your own performance point, but from the right direction.  Buffered
stream I/O is a simple and common function that any system can provide. 
Programs that have more demanding requirements
can provide their own indexing mechanisms or utilize libraries built
on top of primitive streams.  This really is straightforward modern
systems design.

> What you (or I) see as limitations in a particular selection of
> compiler/os/library may be exactly what someone else needs to do
> their job.

The question is, which is the primitive on top of which the other
can be built?

> > Remember this [sub]thread started with the claim that VMS folks had to
> > go to a lot of trouble to support those "evil" C programmers who wanted
> > to do char-by-char input.  My response is: Good, somebody forced them to
> > do what they should do -- namely, implement char-by-char input
> > efficiently.
> 
> While I understand that is your view on what they should do, not all
> will share it. The last time I needed to do character-at-a-time IO was
> to emulate an editor which required a termination character on input
> _unless_ the first character was one particular alphabetic character
> (which had no special meaning in other than the first position).

That you haven't had much need for efficient char-by-char input cannot
possibly be an argument that it shouldn't be provided.

> I
> have been faced with a different set of projects than you, but I have
> my own list of things that "any environment ought to do properly" such
> as file versioning :-).

File versioning can be built on top of an unstructured name system
such as unix's, and programs such as emacs do so.  OTOH, VMS and
DOS/Windows [...]xxxxx.yyy;nnn type stuff is a straightjacket.
 
> >>I have run into programmers making this mistake over and over again.
> >>In recent years their immediate response has been "Gee, it runs fast
> >>on Unix", but in prior years their response was "Gee, it runs fast
> >>on MVS".  Obviously it is only the recent history where the C language
> >>is involved, but the current generation seems much more surprised than
> >>their MVS-centric predecessors.
> >
> > Seems pretty reasonable to me: if Unix or MVS can do it fast, why can't
> > whatever-OS-we're talking about do it fast?  If not, it seems like the
> > fault of the OS, or the standard libraries implementation.
> 
> Sorry if I was unclear, but Unix and MVS could not do the _same_thing_
> fast.  The only commonality was that people coming from Unix and
> people coming from MVS both assumed that the new operating system
> would have the same performance characteristics as the one they are
> coming from.  Now obviously it is impossible for the target operating
> system to fully mimic the behaviour of both Unix and MVS at the same
> time to make both camps happy.

Certainly not if the OS "primitives" are not sufficiently primitive.

--
<J Q B>