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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: CRC in Ada? Date: 1997/03/16 Message-ID: #1/1 X-Deja-AN: 225992076 References: <1997Mar2.220652@nova.wright.edu> <331bf6ce.2832564@news.logica.co.uk> <332B5EBD.3D9E@worldnet.att.net> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-03-16T00:00:00+00:00 List-Id: <> 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!)