Numerics in Ada and C++

Numerics in Ada and C++

[Harry Erwin]

The new standard for C++ introduces a number of numerics template
classes (valarray<>, slice<>, etc.) that are intended to implement smart
arrays built around simple classes that lack side-effects and aliasing
for the new and delete operators. This has been done so that optimizing
compilers can generate code for operations on those classes that
approaches FORTRAN-77 in efficiency. Experience in computational
applications of C++ has indicated that 'mid-level' C++ code (class code
involving branching and temporaries) has been particularly inefficient
and hard for compilers to optimize, and these features were added to
help solve the problem. My question here is whether Ada encounters the
same problems.

-- 
Harry Erwin, herwin@gmu.edu, http://osf1.gmu.edu/~herwin, Senior
Software Analyst for the FAA, PhD candidate modeling how bats 
echolocate and lecturer for CS 211 (data structures and advanced C++).

Re: Numerics in Ada and C++

[Brian Rogoff]

There is some discussion of this topic in the Ada FAQ, and I think one of
DEC's compiler experts reports that well programmed Ada was just as fast 
as F77, given a decent compiler of course. Ada does not have the same 
aliasing problems that C and C++ have, and Ada 95, which is more
permissive than Ada 83 in this regard, forces you to explicitly specify 
aliasing when you want it. 

Incidentally, I was looking for a better Fortran several years ago when I 
"discovered" Ada, after being disappointed by C++. I don't know what the
current state of C++ compilers is wrt templates, but in 1995 it was
abysmal. I don't think I'd switch now, even if all C++ compilers conformed
to the draft ISO standard. Ada 95 is just a *much* better language IMO,
despite numerous little (and big ;-) flaws. Particularly for numerics.

-- Brian 

On Mon, 19 Jan 1998, Harry Erwin wrote:

> The new standard for C++ introduces a number of numerics template
> classes (valarray<>, slice<>, etc.) that are intended to implement smart
> arrays built around simple classes that lack side-effects and aliasing
> for the new and delete operators. This has been done so that optimizing
> compilers can generate code for operations on those classes that
> approaches FORTRAN-77 in efficiency. Experience in computational
> applications of C++ has indicated that 'mid-level' C++ code (class code
> involving branching and temporaries) has been particularly inefficient
> and hard for compilers to optimize, and these features were added to
> help solve the problem. My question here is whether Ada encounters the
> same problems.
> 
> -- 
> Harry Erwin, herwin@gmu.edu, http://osf1.gmu.edu/~herwin, Senior
> Software Analyst for the FAA, PhD candidate modeling how bats 
> echolocate and lecturer for CS 211 (data structures and advanced C++).
> 
> 

Re: Numerics in Ada and C++

[Nick Roberts]

What (numerics) flaws, please?

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Brian Rogoff <bpr@shell5.ba.best.com> wrote in article
<Pine.BSF.3.96.980123145716.16444B-100000@shell5.ba.best.com>...
> There is some discussion of this topic in the Ada FAQ, and I think one of
> DEC's compiler experts reports that well programmed Ada was just as fast 
> as F77, given a decent compiler of course. Ada does not have the same 
> aliasing problems that C and C++ have, and Ada 95, which is more
> permissive than Ada 83 in this regard, forces you to explicitly specify 
> aliasing when you want it. 
> 
> Incidentally, I was looking for a better Fortran several years ago when I

> "discovered" Ada, after being disappointed by C++. I don't know what the
> current state of C++ compilers is wrt templates, but in 1995 it was
> abysmal. I don't think I'd switch now, even if all C++ compilers
conformed
> to the draft ISO standard. Ada 95 is just a *much* better language IMO,
> despite numerous little (and big ;-) flaws. Particularly for numerics.

Re: Numerics in Ada and C++

[Brian Rogoff]

Sorry, I realize now that what I wrote was ambiguous. The flaws I referred
to are not in numerics handling, but about the language in general. Since 
I've mentioned them before, and some are just my opinion (eg lack of out 
mode on function params), I won't rant again. Send me a private e-mail if 
you want a short list. Even with those flaws, I still find Ada a much more 
useable language than the competition.

-- Brian

On 23 Jan 1998, Nick Roberts wrote:

> What (numerics) flaws, please?
> 
> -- 
> 
> Nick Roberts
> Croydon, UK
> 
> Proprietor, ThoughtWing Software; Independent Software Development
> Consultant
> * Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
> *** Always game for a verbal joust (usually as the turkey) ***
> 
> 
> Brian Rogoff <bpr@shell5.ba.best.com> wrote in article
> <Pine.BSF.3.96.980123145716.16444B-100000@shell5.ba.best.com>...
> > There is some discussion of this topic in the Ada FAQ, and I think one of
> > DEC's compiler experts reports that well programmed Ada was just as fast 
> > as F77, given a decent compiler of course. Ada does not have the same 
> > aliasing problems that C and C++ have, and Ada 95, which is more
> > permissive than Ada 83 in this regard, forces you to explicitly specify 
> > aliasing when you want it. 
> > 
> > Incidentally, I was looking for a better Fortran several years ago when I
> 
> > "discovered" Ada, after being disappointed by C++. I don't know what the
> > current state of C++ compilers is wrt templates, but in 1995 it was
> > abysmal. I don't think I'd switch now, even if all C++ compilers
> conformed
> > to the draft ISO standard. Ada 95 is just a *much* better language IMO,
> > despite numerous little (and big ;-) flaws. Particularly for numerics.
> 
> 
>