Re: CRC in Ada?

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <E6n850.3Ct@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <1997Mar6.114441.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>If a programmer _assumes_ that such a construct will be efficient,
>>when in fact it is _not_ efficient within a particular environment,
>>it is a mistake from a performance perspective.
> 
> OK, but where do you draw the line?  Suppose I'm trying to write
> portable software.  I measure the performance on my current
> OS/compiler/libraries, and it's fine.  Can I assume that it will still
> perform as expected on any other platform?

Starting with something which performs well in at least one environment
is certainly a bare minimum.  I happen to think there is a need to plan
for revisiting performance when switching environments.

> Why should I not assume that a get-character-from-file operation takes
> more than a few instructions, on average?  I know how to implement such
> an operation, and it's not hard.  If it turns out that some OS does it
> slowly, then I feel righteous in blaming the OS.  (Of course, from a
> practical point of view, if that OS is popular, then I'll have to live
> with its limitations.)

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.

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.

> 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).  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 :-).

>>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.

Larry Kilgallen