From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9c86eb13dd395066 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: CRC in Ada? Date: 1997/03/07 Message-ID: <1997Mar7.090814.1@eisner>#1/1 X-Deja-AN: 223795168 X-Nntp-Posting-Host: eisner.decus.org References: <1997Mar2.220652@nova.wright.edu> <1997Mar5.131846.1@eisner> <5fmo1k$adm@mulga.cs.mu.OZ.AU> <1997Mar6.114441.1@eisner> X-Nntp-Posting-User: KILGALLEN X-Trace: 857743701/10047 Organization: LJK Software Newsgroups: comp.lang.ada Date: 1997-03-07T00:00:00+00:00 List-Id: In article , bobduff@world.std.com (Robert A Duff) writes: > In article <1997Mar6.114441.1@eisner>, > Larry Kilgallen 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