Re: CRC in Ada?

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Michael said

<<So yes, I DID feel compelled to use an Ada 83 I/O package. I don't think my
  employer would have much appreciated my spending half a day chasing down
  some C file I/O routines to improve the throughput of my test program.>>

No, you felt compelled to *misuse* an Ada 83 I/O package and write highly
non-portable code that relied on the inner workings of sequential_io in
your particular implementation. OK, if you lacked the knowledge to write
the trivial pragma Import for the appropriate C routine (I assume this
if it would have taken you half a day), then you may have been stuck, and
generating this solution may have been the best you could do.

But it was NOT the right solution in Ada, since it did not meet the spec
of the problem except by accident. You cannot expect to do everything in
Ada. Suppose I tell you to write an Ada program that plays a tune on the
speaker.

You have around a C callable routine called Play_Tune that does exactly
what you want, but instead you write a hairy piece of Ada that uses
address clauses to directly address the memory mapped IO port for the
speaker, and write loops with the right frequencies to play the tune.

Your solution is all Ada. Is it therefore superior? no it is perfectly
horrible, and we assume no one would make such a mistake. But your approach
was a (much less obvious and not nearly so horrible) example of the same
mistake.

The fact of the matter is that there WAS no suitable routine in the Ada 83
IO library to solve your problem, just as there is no Play_Note routine.
When you have this situation, then you use pragma Interface, that is what
it is for!

Now in Ada 95, we have Stream_IO which is suitable for solving your problem,
and comparisons of comaprable code using Stream_IO with corresponding C code
are much more meaningful, but it still may be appropriate to use pragma
Interface.

In London a couple of years ago, I gave a talk "Sleeping with the Enemy",
and the theme was that the attitude that C and C++ and ??? are horrible
languages and that you must never go near them is a counter productive
one for Ada programmers. On the contrary, there is lots of useful stuff
there, and a competent Ada programmer knows when and how to take advantage
of it. Note that of course the C or C++ programmer who has a similar
view of Ada (horrible language, don't want to go near it, don't know,
don't want to know) is similarly hobbling themselves.


<<Certainly not Ada versus C, but definitely
  one compiler versus another compiler.
  Pick your I/O package and your language, and 18 minutes versus 27
  seconds to read
  the same file certainly tells you something. HIS compiler (which happens to be
  C++) has buffered file I/O. MY compiler (which happens to be Ada 83) does not
  buffer file I/O>>.

Nope. That misses the point again, you are not comparing one compiler with
another, but rather two completely different solutions, one using a library
routine appropriate to the job, with another solution using an entirely
inappropriate library routine. It would not surprise me at all if the
difference you see, a factor of 30, has nothing at all to do with buffering,
but rather is a natural consequence of the implementation approach for
sequential_IO, which is undoubtedly written to be reasonable for correct
use of the package, and which may well be slow for this clear misuse.

Just to get a bit of a feel for what I mean by sequential_IO being at
a different level of abstraction from the C getchar, look at the following
little bit of code in GNAT's Ada.Sequential_IO.Read:

      --  For non-definite type or type with discriminants, read size and
      --  raise Program_Error if it is larger than the size of the item.

      if not Element_Type'Definite
        or else Element_Type'Has_Discriminants
      then
         FIO.Read_Buf

Now, given a macro substitution approach to generics, it is likely that
this code is optimized away, but in a shared generic approach, it is 
likely to be a real test, and it is certainly a test that would not 
conceivably be present in the C routine.

Does this mean that sequentio_Io is less efficient than the C routine,
no! It means that they are doing different kinds of things. 

If someone compares the peformance of log in C and sqrt in Ada and
tries to draw conclusions about the efficiency of languages, libraries
or compilers from such a comparison, we would immediately see it as
absurd. Comparing getchar in C with sequential_IO.get in Ada is only
slightly less absurd!