Re: CRC in Ada?

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

<<It took my Ada CRC32 18 minutes to calculate the checksum for a 65K file! It too
k
the C++ CRC32 27 seconds to checksum the same file! Timings were performed using
the stopwatch function on my Timex. ;^) Why the difference? File I/O. Turns out
all but about 8-9 seconds of those 18 minutes were spent reading from the hard d
isk!>>

It would be interesting to see how you coded this up, surely you did not
use Text_IO for the I/O (as I say, I have almost never seen people use
Text_IO for such tasks, it is not designed for that kind of use, and
using it for this purpose is inadvisable). Whether or not the difference
you saw is due to poor performance of the I/O packages, or poor choice
of how to use them is hard to say.

It is always possible to match C++ performance in Ada if you are using
a reasonable compiler (GNAT is one, but there are certainly others),
and if you know what you are doing.

Often differences in speed come from poor implementation, it is true (this
can happen either on the C++ or Ada side, I have run into a number of
really horrible performance problems in compilers for all sorts of
languafges), but more usually comes from coding in a way that seems
equivalent, but is not.

For instance, you may often find that the Ada libraries have additional
overhead from being task safe. Very often C runtimes are not task safe
(this might account for example for malloc being faster than new -- in
such a case recoding malloc as new is NOT an accurate translation -- what
you need to do if you want a tasking unsafe allocator is to program one
yourself, easily done.

Similarly the I/O packages of C and Ada are very different.

When you write an applicatoin in Ada, you obviously reuse existing
libraries as much as you can. Thanks to the unmatched capabilities
of Ada 95 in interfacing to other languages, it is almost as easy
to use libraries in other languages as those in Ada 95 (try using
COBOL libraries from C in a portable manner for example -- can't be 
done). 

If you want to do I/O, you have a wide variety of packages available,
some in Ada, some in C, and, don't forget this possibility if you
are interested in high level efficient indexed file access, some in
COBOL. Often all you need for such interface is a simple pragma Import.
Perhaps, e.g. in the case of COBOL, you need a few simple glue functions.

In the context of writing a large application, such interfaces are isolated
to small numbers of packages, and as I have said before, it seems an
advantage, not a disadvantage that Ada can so easily interface to other
languages. Indeed, what on earth would be the point in dfuplicating something
in Ada that is already available in other standard libraries?

Text_IO is convenient for small scale or occasional use for small amounts
of formatted output (compare it to ACCEPT and DISPLAY use in COBOL). It is
not the appropriate interface for large scale I/O where performance is
critical.

One other thing here is that I generally find that when people recode a
piece of code written in language X into language Y, they often do a much
worse job than if they wrote a new program from scratch in Y. It is much
too easy to copy inappropriate approaches and design from the other
implementation. It would be an interesting experiment to code up something
like the CRC efficiently in Ada, which of course can be done, and then
have it translated to C++. For example, if one used packed arrays in Ada,
you can often get some very efficient code that does not map nicely into
C++ at all. The proper approach for recoding this in C++ is to redesign
the data structures, but it would be a path of lesser resistance to emulate
the packed stuff inefficiently in C.

(not that it could not be emulated efficiently, but that is more work!)