Re: Reaching traditional engineering

[intros@earth (Introspect Technologies)]

Kevin Weise (weisek@source.asset.com) wrote:
: In article <3d03j7$q21@gnat.cs.nyu.edu>,
:   Robert Dewar <dewar@cs.nyu.edu> wrote:
: >I assume you are aware of the Cray/Ada effort which was certainly aimed
: >at least partly at their Fortran community.
: >
: Well, I have to respond to this one.  WADR, Robert, my wife has been doing
: benchmarking of various Ada compilers on various target platforms for
: some time now.  My discussions with her lead me to conclude that the
: Cray Ada effort was basically a token effort, possibly just done in
: response to, or in anticipation of, a contract for a DoD contractor.

I used Cray Ada for a couple of years at the National Test Facility.  The
primary motivation for the development of the Ada compiler was juicy
DoD/SDI/R&D-type contracts.  The NTF was (at the time) taking the mandate
seriously and insisted that Cray provide an Ada compiler as a condition
for keeping their machines on-site.  I don't know whether the government
provided any funding to Cray to help them along. 

The compiler development group was (is?) very dedicated to Ada and
expressed their hopes that Ada would catch on in the scientific community. 
I don't think Cray put any marketing push behind it, however. 


: The compiler itself is easy to break (esp. with generics),

I never saw this behavior.  On the contrary, the compiler was reasonably
robust.  The biggest headaches were with the (very primitive) Telesoft 
library manager that they ported to the Cray.

: and generates
: poor code (yes, I know, it uses a common back end with all other
: language translators).

My benchmarks (remember, this is 2-3 years ago) showed that standard 
computations in Cray Ada (including range and bounds checking, etc) took 
approximately 10% longer than Cray C and 20% longer than Cray Fortran.  
This is certainly not "poor code".

The optimizer worked fine and Cray taught a class in how to write
vectorizable code.  The Cray architecture is very peculiar and requires a 
specific (and unusual) style of coding.  I can see how someone could get 
poor performance if they didn't know "the tricks".  In fact, writing to 
get the best performance often necessitated writing Ada in a very 
"non-Ada" way (very frustrating!).


: Unless they've fixed it recently, a delay statement
: is guaranteed to result in a wait of *AT LEAST* 2.0 seconds, regardless
: of the requested value.  While all this is not illegal, it certainly does
: not entice any engineer to switch to Ada.

We never used Cray tasking or delays so I can't speak to this issue.


: When it comes to Cray Ada, JUST SAY NO!  (Actually, my personal opinion
: is, when it comes to the Cray, just say SGI!  And we know they have a
: good Ada implementation!)

IMHO, the problem with Cray Ada was the Cray machines, not Ada.  The 
speed advantages of a vector-based architecture are not worth all the 
programming hoops you have to jump through, especially if your 
application doesn't lend itself to vectorization.  I agree that SGI (and 
DEC and HP and other general-purpose computers) are more cost-effective 
and are better hosts and targets for Ada development.


: ----------------------------------------------------------------
: Kevin J. Weise			weisek@source.asset.com
: COLSA Corporation		Voice - (205) 922-1512 ext. 2115
: ----------------------------------------------------------------
: "Admire those who seek the truth;
:   avoid those who find it."		Marcel Proust

Douglas Arndt (member, Team Ada!)
Introspect Technologies, Inc.
PO Box 1135
Colorado Springs, CO  80901-1135
(719) 634-5744
(719) 634-1163 fax
intros@usa.net
---------------------------------------------------------------------------
                                          "Facts are just facts.  You can't
                                           have opinions about facts."
 
                                                - Professor Peter Schickele
---------------------------------------------------------------------------
--