Print

Print


> From [log in to unmask]  Thu Dec  3 12:53:50 1998
> Subject: Re: Ada95 for Deep Space Missions .. can it compete?

Personally, for a "critical" system, or one that's difficult to maintain
(because it's operating millions of miles away),  if it were true that Ada
was too slow, I'd rather buy a faster processor than accept some of the
other risks and costs associated with C or C++.

> I guess someone posted my message to some Ada list, which I hadn't
> intended.

To quote a recent more popular space story, "Wasn't me!"  But please
accept my apology on behalf of my fellow Team Ada members.  If you wish,
you can mail "[log in to unmask]" and ask that we abandon this thread, or
leave you out of it.

> Anyway, the point of the example is that the recursion is done at
> COMPILE time, via recursive templates. With inlining and
> optimization the result is simply the constant 720 (from 6!). It's
> not meant as a practical example.

I can't say how many Ada compilers would be that smart.  As someone else
already pointed out, GNU C++ does figure out that it is a constant 720.
But that optimization is not possible in any language if the input (6) is
not a compile-time constant.

> The connection to Blitz is that they use similar techniques.
>
> As for generic vs template capability, it comes down to: can the
> example be recoded into Ada? I think not, because there is no way to
> break the recursion at compile time. I don't have access to an Ada
> compiler at the moment, or I'd try it myself.

GNAT is free, if you can afford 15 to 100 minutes (depending on platform)
to download and install it.  If you're really ambitious, you can install
g++ and g77 for comparisons (C++ and Fortran 77 compilers that use the
same code generator as GNAT Ada 95.

> One can imagine optimizers of any degree of sophistication, and we
> can always say it should do a particular optimization. But does it
> really? ....

One way to find out ...  :-)

> .... The goal of Blitz is to match FORTRAN speed, while still
> retaining the use of operators, etc. In their experience, optimizers
> do not currently do a good job with matrix expressions expressed
> pairwise. Maybe this is only a C++ problem.
>
> For more details, check out the papers under "Papers and Talks" on
> the Blitz site:

Thanks, I will--if _I_ can spare the time.  :-)