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: bobduff@world.std.com (Robert A Duff) Subject: Re: CRC in Ada? Date: 1997/03/06 Message-ID: #1/1 X-Deja-AN: 223446406 References: <1997Mar2.220652@nova.wright.edu> <1997Mar5.083233.1@eisner> <1997Mar5.131846.1@eisner> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-03-06T00:00:00+00:00 List-Id: In article <1997Mar5.131846.1@eisner>, Larry Kilgallen wrote: >While theoretical computing and Alan Turing may be centered on >the equivalence and correctness of programs, in the real world >performance is also a consideration. Just as those using intense >computation will be concerned about the efficiency of their >algorithms, those accessing large databases will take care >regarding order-of-access so as not to go skipping over the >whole thing when some locality-of-reference would yield better >performance. Those reading sequentially from disk should >likewise concern themselves with performance, and 512 calls >to even the lightest-weight library is too much if a single >call would do. For the stated problem (CRC) reading large >blocks is a clear win. Agreed, but that's what inlining is for. All I was saying is that there should be a standard package that does efficient I/O, with buffering, and of course you want to inline a call that just bumps a pointer and grabs a character out of a buffer (except in the rare case where the buffer is exhausted). Unfortunately, Text_IO has an awful lot of nearly-useless cruft in it. But why can't Stream_IO fit the bill here? >> I'm not sure why reading a file character-by-character is "C-like". >> It seems like the natural way to write lots of programs, in any >> language. The underlying language and OS should ensure that it can be >> done efficiently (by making the "give-me-a-char" routine read from a >> buffer whenever appropriate). And I should have added, "and by making that thing inline-able". Actually, I suppose the OS has little to do with it -- obviously you can't afford to do a system call (i.e. enter supervisor mode) on every character. >In my experience it is generally C programmers who make this mistake. >Perhaps it because many of them come from a Unix background where there >is no strong sense of a "record". On the other hand, it may just be >that there are so many C programmers that statistically speaking most >of the mistakes made will be made by a C programmer. I still don't think it's a "mistake" to expect buffering to be done by standard packages, rather than by every user's program. I mean, you have to tell the thing that you're planning to read sequentially through the file, but beyond that, the application program shouldn't have to worry about it. (When I programmed on VAX/VMS, I was appalled at the complexity of the Record Management Services. I still don't know why all that complexity is necessary, as compared to the Unix notion that a file is a sequence of bytes. But I could be wrong -- I write compilers, mostly, which don't need "fancy" I/O facilities.) Note that Ada compilers don't typically use Text_IO to read the source code! ;-) - Bob