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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Q: access to subprogram Date: 1996/07/30 Message-ID: <4tkh3s$fek@goanna.cs.rmit.edu.au> X-Deja-AN: 171066681 references: <4rb9dp$qe6@news1.delphi.com> <4re2ng$t7u@wdl1.wdl.loral.com> <4rqbo9$b02@goanna.cs.rmit.edu.au> <4rvnbr$amu@goanna.cs.rmit.edu.au> <4snh9b$2tl@goanna.cs.rmit.edu.au> <4svdk6$6qu@goanna.cs.rmit.edu.au> <4t4siv$bh2@goanna.cs.rmit.edu.au> <31F8E0D9.2FEA@lmtas.lmco.com> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-07-30T00:00:00+00:00 List-Id: Ken Garlington writes: >Richard A. O'Keefe wrote: >> >> Ada (using generic instantiation) >> compiled with gnatmake -gnatp -cargs -O4 >> Size: 94 lines. >I don't know how to read the gnat command lines, so could some one tell me >if this means all exceptions are suppressed? If I may quote from "gnatinfo.txt" To disable constraint checks, compile the program with th "-gnatp" option. This is equivalent to having Pragma suppress applied to everything. So yes, it does suppress everything. -O4 is high optimisation level. >Also, is source line size being given here as a measure of efficiency? Don't be ridiculous, of *course* not. The number of source lines required to express the same algorithm naturally is an inverse measure of EXPRESSIVENESS, and has no intrinsic connexion whatsoever with efficiency. Why would you imagine otherwise? The sole measure of efficiency I proposed is TIME. >What were the other measures compared to the alternatives >(readability, reusability, etc.)? Obviously, if it takes you more lines, it's likely to be harder to read. I have no objective measurements of readability. I believe that I am equally familiar with all four languages (I have, and have studied hard, the standards for all of them, and have written a fair amount of code in all four). In this case: Scheme is the most readable. Pascal comes close; no warping to fit the language. The C code is shorter, but it has some nasty internal coupling, so I rank the Ada code (all connections explicit) as more readable (though longer) than the C. As for re-use, where I can be objective: Scheme is by far the most reusable, having no constraints on reuse at all. The Pascal code is cut-and-paste reusable; in Turbo Pascal or Think Pascal or ISO Pascal Extended the integration code could be in a unit/module. The Ada code is as reusable as the Pascal code, in the sense of requiring no modifications for reuse, but has higher reuse costs. (It takes more source code to effect reuse, and generates more object code). The C code was not written for re-use. The need to explicitly simulate funargs by passing environment pointers pushes up reuse cost; unlike the Scheme and Pascal code you cannot combine the integration functions with *existing* real-valued functions but must write glue code. >> I guess Scheme running 3 times faster than Ada or Pascal is not "intuitive" >> for many programmers. >It's certainly not intuitive to _me_. However, I would certainly have no problem >with a statement that a particular Scheme toolset might generate code that is >three times more efficient than an Ada _toolset_, for a given host/target >platform. (Do we really believe GNAT is the most efficient Ada compiler available, >for example? I keep reading that not all optimizations have been implemented in >GNAT yet...) For sure. Stalin has a fair bit in common, I think, with VORTEX, with the Self compiler, and with Stanford's FUSE. The common factor here is tools that start with very high level languages and optimise the heck out of them; there are analyses and transformations that they perform which I expect Gnat will _never_ perform. Partly this is because they deal with simpler languages. For Ada, I think it is more important to get tasking absolutely right than to perform aggressive optimisations. Note also that in a previous thread in this group I was pleased to report that GNAT's time for a certain numerical program was close to the time from SPARCompiler Fortran 77. Whether or not GNAT is the best, it is pretty darned good. But please, don't attack a proposition your interlocutor never defended. Gnat is the best Ada compiler *I've* got, that's all. So far I have tried this example in Clean 1.0 -- not the latest version Gambit 2.2.2 -- pretty recent, but maybe not the latest Think C 5.0 -- far from the latest version on the Mac Gnat 3.04 -- not the latest version SPARCompiler C 4.0 -- is the latest version SPARCompiler Pascal 4.0 -- is the latest version Gcc 2.7.2 -- probably not the latest any more Stalin 0.6 -- latest generally available on an UltraSparc. Why these versions? Because that's what I've got. That's all. Remember: I am not interested in establishing which _language_ is the best. My sole concern was to provide an example showing that the restrictions on procedure parameters which make my example *impossible* to write directly in Ada 95 are not *necesary* for efficiency. This does not, unfortunately, prove that it would be easy for _any_ Ada vendor to support Algol-style funargs, still less that it would have been affordable for _every_ Ada vendor to do so. ALL my example can accomplish, and I believe it does accomplish this, is to show that Algol/Pascal-style funargs are fully consistent with more efficiency than I can currently get from a good Ada compiler. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.