Re: CRC in Ada?

[ohk@edeber.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB)]

In article <1997Mar6.091150.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

   In article <OHK.97Mar6080224@edeber.tfdt-o.nta.no>, ohk@edeber.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

   > In article <1997Mar5.131846.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

   >    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.
   > 
   > I think you are missing something here. Altough in Unix it IS possible
   > to do reads of arbitrary length, the standard IO library of C
   > definitely does IO in blocks. The getc/putc functions are
   > usually implemented as macros, which just manipulate the buffer. Of

   And relying on performance characteristics of a particular implementation
   which are not mandated from implementation to implementation brings
   problems.  (Perhaps this implementation technique _is_ mandated,
   but it is not something I would know.)

No, it is not mandated, but every implementation I have ever seen,
has done it that way. NB, this has NOTHING to do with Unix, but with
the C standard IO library. And of course, you are right, language and
libraray specifications do not in general say anything about
performance. You cannot count on block IO being efficient either, but
I'll agree it's a good bet :-)

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

   > It should be no harder to implement the putc/getc funtions on any
   > other OS which allows you to do character IO in blocks, than it is in Unix.

   And any vendor in the non-Unix space can choose to emulate as many
   Unix characteristics as they choose, including performance-related
   ones or not.

Again, the C standard IO library has nothing to do with Unix. The
question is whether the vendor has implemnted this library efficiently
or not, based on the mechanisms available in the OS.

   > It may be a mistake in some cases, but talking about "this mistake" is
   > a vast oversimplification. Surely, there is nothing conceptually wrong
   > with having a set of single character IO operations like putc, getc,
   > and ungetc?

   It is a mistake to assume performance semantics (if that is the term)
   which are not present in the target environment.

I agree 100%. Which means that you have to run your program and
profile it anyway.

   Don't get me wrong, I think there are many instances for non-portable
   code in the world. However just because something written in Ada (or
   C) will compile and get the right answer in another environment, that
   does not mean it is portable from the standpoint of the end user who
   must wait for the results.

   Larry Kilgallen

There is no such thing as portable, high-performance, code which does
IO :-)

Ole-Hj. Kristensen