Numerical Computation and Ada95

Numerical Computation and Ada95

[N&J]

Hi all,
I have posed the question whether Ada95 is suitable for numerical
programming at the newsgroup of numerical analysis.
I asked if Ada95 is better that Fortran90/95 and C++ for writing programs
for numerical computation and the reply was that the Ada language
specification requires extensive
run-time checks which slows down the programs. I thought it would be better
to ask your opinion too. I have noticed that there are too few numerical
programs in Ada95 for numerical computation is the above fact the real cause
for this? Finally would you suggest someone to use Ada95 for numerical code?

Thanks,
John

Re: Numerical Computation and Ada95

[David Starner]

On Wed, 9 May 2001 22:13:31 +0300, N&J <nikogian@hotmail.com> wrote:
> I asked if Ada95 is better that Fortran90/95 and C++ for writing programs
> for numerical computation and the reply was that the Ada language
> specification requires extensive
> run-time checks which slows down the programs. 

There's always the question on whether you want fast programs or 
correct programs. (-: Most Ada compilers offer switches to turn off
run-time checks, so there should be practically no difference 
between the speed of Fortran, C++ and Ada. (In practice, Ada seems
to be slightly slower (10-20%) even with the checks turned off. This
will of course vary widely depending on your program and enviroment.)

> I have noticed that there are too few numerical
> programs in Ada95 for numerical computation is the above fact the real cause
> for this? 

Ada has various stigmas in the programming community and Fortran users
seem to be reluctant to ever give up Fortran. (I have a teacher who
still complains that changes between Fortran 66 and Fortran 77 broke
some code of his. He is also of the Fortran is the universal programming
language mindset.)

> Finally would you suggest someone to use Ada95 for numerical code?

(Donning abestos suit.) Probably not. Fortran and C++ have a variety
of optimized, tested numeric libraries, like Lapack and Blitz, that
are generally missing from Ada. (I'm sure someone will pop up with
some Ada binding to them, or one of the numeric libraries for Ada.
The first tends to be slower than just using the real thing, and if
you're using Lapack, why not just use Fortran? The latter are
neither optimized or heavily bug tested.) Ada does have the
advantage in having a free, highly ported compiler (GNAT), where as
Fortran 90/95 doesn't.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Numerical Computation and Ada95

[Ted Dennison]

In article <9dc4sh$ru5$1@ulysses.noc.ntua.gr>, N&J says...
>I have posed the question whether Ada95 is suitable for numerical
>programming at the newsgroup of numerical analysis.
>I asked if Ada95 is better that Fortran90/95 and C++ for writing programs
>for numerical computation and the reply was that the Ada language
>specification requires extensive
>run-time checks which slows down the programs. I thought it would be better
>to ask your opinion too. I have noticed that there are too few numerical
>programs in Ada95 for numerical computation is the above fact the real cause
>for this? Finally would you suggest someone to use Ada95 for numerical code?

This has been asked many times before. You might have been better served by
doing a groups.google.com search on it. 

The basic conclusions were generally:

o  Compilers vary so much in the quality of their optimization (even within the
same language) that it really doesn't make sense to talk about relative speeds
of different compiled languages.

o  There is nothing about Ada that makes it inherently slower than any other
language.

o  Theoreticly, one ought to be able to get *better* optimization out of Ada
than Fortran or C for the same effort, as all the rules and limitations of Ada
language give the compiler a lot more information to work with.

o  Fortran users tend to care a lot more about number-crunching speed than other
language users, so their compilers generally optimize that stuff better.

o  In real-world terms none of this hypothetical stuff matters. What you need to
do is compare the speed of the code generated by the compilers you are
considering, for the kinds of operations you are going to be performing. Even
here you have to be careful, as its easy for a neophyte in any langugage to
stumble over a construction that is needlessly difficult for their compiler to
optimize.

Just to give an example, the Aonix Ada compiler for NT doesn't provide *any*
optimization options whatsover (at least it didn't last I used it). The Gnat Ada
compiler provides the typical "-On" where n is in 0..3, along with some others.
The x86 vxWorks GreenHills compiler we use here for real-time work provides
flags for all sorts of arcane optimization options. Now it would be quite easy
for someone to compare what the Aonix compiler does with an algorithm to what a
serious numerical Fortran compiler does, but it wouldn't exactly be a fair
comparison.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Numerical Computation and Ada95

[James Rogers]

N&J wrote:
> 
> Hi all,
> I have posed the question whether Ada95 is suitable for numerical
> programming at the newsgroup of numerical analysis.
> I asked if Ada95 is better that Fortran90/95 and C++ for writing programs
> for numerical computation and the reply was that the Ada language
> specification requires extensive
> run-time checks which slows down the programs. I thought it would be better
> to ask your opinion too. I have noticed that there are too few numerical
> programs in Ada95 for numerical computation is the above fact the real cause
> for this? Finally would you suggest someone to use Ada95 for numerical code?
> 
> Thanks,
> John

You might look at the work done by Martin Stift at

http://fedelma.astro.univie.ac.at/web/home.html

Martin has very successfully used Ada in the field of Astrophysical
calculations. This is a field where Fortran is the traditional language
of choice. Martin explains why he believes Ada is a much better
choice.

Jim Rogers
Colorado Springs, Colorado USA

Re: Numerical Computation and Ada95

[Dr Adrian Wrigley]

Hi,

I believe that Ada95 is well suited to numerical programs.  Although I have
only used the "77" flavor of Fortran, and prefer C to C++, the usual
advantages of Ada shine:

Legible programs, more thorough correctness checks, etc.

I would also add that Ada generics make it much easier to express the
algorithms, without being burdened by instance specific details.
If the code is algorithmicly rich, you'll get efficient, correct code
in less time than the other languages mentioned, once you know
the languages equally well. Interfacing to other language libraries
is usually straightforward, but still more work than keeping it all
in one language.  If you're just bolting together other people's
code, the pressure is always to use the same language as they do.

Another thing I have found is that writing correct multi-threaded code
is much easier with Ada95 than anything else I have used, making it
simple to take advantage of multiprocessor machines, and concurrent
computation and I/O.  This could be of relevance with large memory
problems going into swap a lot.

The issue of performance is one of my biggest worries when choosing
Ada95 over other languages, when speed is critical.  Comments elsewhere
in this thread suggest that this is not normally a problem, but I
have found that great care is needed to avoid inocuous constructs which
result in slow code.  Sometimes this prevents writing the code in
the most "natural" way.  Things may be better now with the latest
GNAT (I developed most of my performance-critical code under GNAT 3.11, 3.12).
Of course, you need to take great care in C or C++ too.  Fortran(77) seemed
to be a lot more robust in performance terms, perhaps because it was
quite limited in what you could do.  Try some simple example comparisons
in your proposed environments.  They may not be representative, but
at least you'll have some idea what to expect with "real" code.

A lot will depend on whether you can "go it alone", or whether you
need support from your colleagues, boss, customers etc., as well as
the size of project and penalty for failure.  If you are in a big
department hooked on F90, or working on a major new project for
your employer, the biggest risks may be political.  You would need
a lot of confidence, with sound justifications to introduce Ada.
The skeptics will be convinced that all the problems you encounter
are due to the use of Ada.  Usually they'll be wrong.  If you don't
have the confidence to use Ada for a project, don't try.  Go home
and familiarize yourself with the technical issues surrounding the
language on your own (Linux) machine.
--
Adrian Wrigley

Re: Numerical Computation and Ada95

[N&J]

Hi all,
From what you said I undestand that nobody has ever compared Ada's timing
performance with Fortran77/90/95, C and C++ in programs that require lots of
arithmetic and logical operations (perhaps FFT). I think I will try to do it
when I learn Ada95 better

Thanks for your help,
John

P.S I am still a student and I work for myself that's why I am always
looking for new things

Re: Numerical Computation and Ada95

[David Starner]

On Thu, 10 May 2001 08:45:25 +0300, N&J <nikogian@hotmail.com> wrote:
> From what you said I undestand that nobody has ever compared Ada's timing
> performance with Fortran77/90/95, C and C++ in programs that require lots of
> arithmetic and logical operations (perhaps FFT). I think I will try to do it
> when I learn Ada95 better

Not true; many people have probably compared it. The point was,
thought, that keeping the platform constant, the speed ratio of your
conversion of Fortran 77 code to Ada will differ from the speed
ratio of my Ada code converted to Fortran 77 will differ from two
independent writings of the same algorithm in different languages,
which will differ from another pair of independent writings of the
same code. Then you have to worry about compilers; if GNAT makes one
piece of code run 45% faster then when compiled with ObjectAda, and
ObjectAda makes another run 52% faster than when compiled with GNAT,
which compiler do you use?

Performance between languages is impossible to measure; one system
change can change all your results. No matter what you say, there
will be expections. Someone quoted an old IBM machine that ran small
APL programs faster than any PL/I program could be run. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Numerical Computation and Ada95

[tmoran]

>From what you said I undestand that nobody has ever compared Ada's timing
>performance with Fortran77/90/95, C and C++ in programs that require lots
>of arithmetic and logical operations (perhaps FFT).  I think I will try to
>do it when I learn Ada95 better
  There was a substantial comparison someplace (perhaps Ada Letters?)
some time ago, but I don't remember just when.  Try looking in
www.adapower.com, www.adahome.com, or www.adaic.org  A simple minded
transliteration from one language to another can have pitfalls,
accessing arrays in row-major vs column-major order being an example.
When I went to translate an algorithm from "Numerical Recipes in
Fortran" it became obvious during the translation to Ada that the
Fortran version was doing some extra, wasted, iterations.  Do you want
to compare the Fortran version against an exact translation that
includes those wasted cycles, or against an Ada version that preserves
the algorithm, but not the poor coding?  It's not always obvious
what's the appropriate comparison.

Re: Numerical Computation and Ada95

[Martin Dowie]

taken from:

http://www.adaic.org/docs/present/whyada/tsld013.htm

"For duplicate functions written in C and Ada for a C30
 DSP using the tartan compiler, comparisions indicated
 that the Ada code was faster than the C code"

N&J <nikogian@hotmail.com> wrote in message
news:9dc4sh$ru5$1@ulysses.noc.ntua.gr...
> Hi all,
> I have posed the question whether Ada95 is suitable for numerical
> programming at the newsgroup of numerical analysis.
> I asked if Ada95 is better that Fortran90/95 and C++ for writing programs
> for numerical computation and the reply was that the Ada language
> specification requires extensive
> run-time checks which slows down the programs. I thought it would be
better
> to ask your opinion too. I have noticed that there are too few numerical
> programs in Ada95 for numerical computation is the above fact the real
cause
> for this? Finally would you suggest someone to use Ada95 for numerical
code?
>
> Thanks,
> John
>
>

Re: Numerical Computation and Ada95

[Pat Rogers]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9dc6io$a2g2@news.cis.okstate.edu...
> On Wed, 9 May 2001 22:13:31 +0300, N&J <nikogian@hotmail.com> wrote:
> > I asked if Ada95 is better that Fortran90/95 and C++ for writing
programs
> > for numerical computation and the reply was that the Ada language
> > specification requires extensive
> > run-time checks which slows down the programs.
>
> There's always the question on whether you want fast programs or
> correct programs. (-: Most Ada compilers offer switches to turn off
> run-time checks, so there should be practically no difference
> between the speed of Fortran, C++ and Ada. (In practice, Ada seems
> to be slightly slower (10-20%) even with the checks turned off. This
> will of course vary widely depending on your program and enviroment.)

Which of the above two assertions do you believe?  You've said "practically
no difference" and "in practice, Ada seems to be slightly slower (10-20%)".
Absent any justification, that is spreading FUD, IMHO.  The trailing
qualifier (that it varies widely) doesn't undo the damage.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Numerical Computation and Ada95

[Ted Dennison]

In article <9dc6io$a2g2@news.cis.okstate.edu>, David Starner says...
>
>between the speed of Fortran, C++ and Ada. (In practice, Ada seems
>to be slightly slower (10-20%) even with the checks turned off. This
>will of course vary widely depending on your program and enviroment.)

You mean the Ada *compilers* you looked at seem to be slightly slower than the
Fortran *compilers* you've looked at. The language itself is not slower, only
the implementations you may have looked at. As I said in another post, there's
no reason why someone can't put the effort into making an optimizing Ada
compiler that's better than any optimizing Fortran compiler. The problem is that
some (not all) Fortran compiler writers care about optimization more than your
typical Ada compiler writer does. If you compare one of these uber-optimizing
Fortran compilers to a random sample of Ada compilers, of course you're going to
see a big difference. It would be odd if you didn't.

>(Donning abestos suit.) 
2 paragraphs too late, I'm afraid. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Numerical Computation and Ada95

[Martin Stift]

>From what you said I understand that nobody has ever compared Ada's timing
>performance with Fortran77/90/95, C and C++ in programs that require lots
>of arithmetic and logical operations (perhaps FFT).  I think I will try to
>do it when I learn Ada95 better

>The issue of performance is one of my biggest worries when choosing
>Ada95 over other languages, when speed is critical.  Comments elsewhere
>in this thread suggest that this is not normally a problem, but I
>have found that great care is needed to avoid inocuous constructs which
>result in slow code.  Sometimes this prevents writing the code in
>the most "natural" way.  Things may be better now with the latest
>GNAT (I developed most of my performance-critical code under GNAT 3.11, 3.12).
>Of course, you need to take great care in C or C++ too.  Fortran(77) seemed
>to be a lot more robust in performance terms, perhaps because it was
>quite limited in what you could do.  Try some simple example comparisons
>in your proposed environments.  They may not be representative, but
>at least you'll have some idea what to expect with "real" code.


Well, I have had the chance to compare the numerical performance of Ada83
and of Ada95 with Fortran77 with quite satisfactory results.

Back in 1994 I had a program written in Fortran77 which carried out spectrum
synthesis in magnetic stars. This program had been translated into Ada83 with
considerable restructuring of the code in order to take advantage of the superior
expressive power of Ada83. The code did mostly number-crunching.

Running the respective Fortran and Ada83 codes on a DEC Alpha under
OpenVMS resulted in the Ada code being about 5% slower than the Fortran
code. At that time I had 20 years experience in Fortran and 1 year experience
in Ada83.

In 1997 I definitely switched to Ada95, working on a Silicon Graphics Origin200
4-processor server. In the beginning the GNAT compiler running under IRIX
had to use the old and slow o32 ABIs whereas with Fortran one could use the
much faster new n32 ABIs. In some extreme cases, execution times could differ
by as much as a factor of 3. However, when using the o32 ABIs for both Fortran
and Ada95, performance was about the same to within 10-20%.

The situation has greatly improved since. Although Sgi is known for its advanced
Fortran compiler technology, the GNAT compiler by now performs impressively.
The famous "abstraction penalty" can be encountered both in Fortran and in Ada95.
The calculation of the Voigt-Faraday function, which is the most time-consuming
part of my code, in Ada95 takes about the same time (within 5-10%) as with Fortran.

I made another test with a celestial mechanics program which I translated directly
into Ada without any substantial modifications to accomodate Ada features. Again,
the program just does number-crunching, extensively using more-dimensional
arrays which should be treated very effectively in Fortran. Still, with GNAT 3.13,
the Ada95 version was  f a s t e r  than the Fortran77 version.

One of the major advantages of supercomputing with Ada95 is the fact that it
provides a thread-parallel model. You don't have to resort the MPI but can
parallelise your code with kernel language constructs. Protected objects have very
little overhead and are perfectly suitable for synchronisation. Tasks also are
easy to handle. At present, I am running my codes on an Origin2000, using up to
64 processors (Amdahl's law makes it impracticable to use more processors for
the problems at hand).

Summarising I can say that Ada95 is a viable alternative to Fortran. It is fast and
safe, the parallel constructs are easy to use. More information on supercomputing
with Ada95 can be found in

Stift, M.J., 1998.
Astrophysical Supercomputing: Ada95 as a safe, object oriented
alternative.
In Reliable Software Technologies --Ada Europe '98,
ed. L. Asplund, Lecture Notes in Computer Science, Vol. 1411, p. 128-139.

Stift, M.J., 1998.
Scientific programming with Ada95: object oriented, parallel and safe.
Computers in Physics, Vol. 12, No. 2, p. 150-158.


These publication give some ideas as to how the Ada95 features can be applied
to (astro)physical problems. Synchronisation as presented in 1998 is somewhat
outdated now, the solutions presented in the above-mentioned papers are only
useful on small machines like my Origin200. They have in the meantime been
replaced by much more efficient algorithms that work on large supercomputers.

Martin Stift


-- 
Posted from fedelma.astro.univie.ac.at [131.130.36.112] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Numerical Computation and Ada95

[Ted Dennison]

In article <9dd9tb$1o56$1@ulysses.noc.ntua.gr>, N&J says...
>From what you said I undestand that nobody has ever compared Ada's timing
>performance with Fortran77/90/95, C and C++ in programs that require lots of
>arithmetic and logical operations (perhaps FFT). I think I will try to do it
>when I learn Ada95 better

Again, you *can't* make such a comparison. The best you can do is compare
*implementations*, which have way more variables than just the source language.

Suppose I took my super-optimizing RTOS Ada compiler, compared it to the
(mythical) $50 HappySoft Win95 Fortran compiler for students, and discovered
that Fortran was %50 *slower*. What exactly would I have proved? Only that
HappySoft doesn't care about optimization as much as the authors of my Ada
compiler. 

If you are wondering about *theory*, theoreticly Ada (with the checks turned
off) ought to be exactly the same speed for arithmetic and logical operations as
C, C++, and Fortran before optimization, and the same speed or *faster* than any
of them after optimization, due to the extra info that can be fed to the
optimizer. But theory won't get you far in the Real World.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Numerical Computation and Ada95

[Ted Dennison]

In article <3afa4879$1@pull.gecm.com>, Martin Dowie says...
>http://www.adaic.org/docs/present/whyada/tsld013.htm
>
>"For duplicate functions written in C and Ada for a C30
> DSP using the tartan compiler, comparisions indicated
> that the Ada code was faster than the C code"

As I remember, Bevin Brett reported similar results with the DEC Ada compiler.
The problem with taking this at face value is that there's no way to tell if
this might be due to the effects of the language, more effort being spent on
optimizing Ada (at the time it presumbably had more military users than the C
compiler), utilizing lessons-learned from implementing the C compiler earlier,
or the superior brain-power of Bevin and everyone else involved with the Ada
compiler.

Still, its a nice piece of evidence to have in one's pocket when those "Ada is
slow" threads pop up.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Numerical Computation and Ada95

[Martin Dowie]

A fuller account can be found at

http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html

by John Stare of Tartan Inc.


Ted Dennison <dennison@telepath.com> wrote in message
news:qkxK6.993$bi2.76229@www.newsranger.com...
> In article <3afa4879$1@pull.gecm.com>, Martin Dowie says...
> >http://www.adaic.org/docs/present/whyada/tsld013.htm
> >
> >"For duplicate functions written in C and Ada for a C30
> > DSP using the tartan compiler, comparisions indicated
> > that the Ada code was faster than the C code"
>
> As I remember, Bevin Brett reported similar results with the DEC Ada
compiler.
> The problem with taking this at face value is that there's no way to tell
if
> this might be due to the effects of the language, more effort being spent
on
> optimizing Ada (at the time it presumbably had more military users than
the C
> compiler), utilizing lessons-learned from implementing the C compiler
earlier,
> or the superior brain-power of Bevin and everyone else involved with the
Ada
> compiler.
>
> Still, its a nice piece of evidence to have in one's pocket when those
"Ada is
> slow" threads pop up.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Numerical Computation and Ada95

[Jeffrey Carter]

David Starner wrote:
> 
> There's always the question on whether you want fast programs or
> correct programs. (-: Most Ada compilers offer switches to turn off
> run-time checks, so there should be practically no difference
> between the speed of Fortran, C++ and Ada. (In practice, Ada seems
> to be slightly slower (10-20%) even with the checks turned off. This
> will of course vary widely depending on your program and enviroment.)

This, I am glad to say, is simply wrong. Robert Dewar has a suite of
equivalent Ada and C programs that generate *identical* object code when
compiled with gcc. Back in the dark days of Ada 83, the highly optimized
Tartan Ada compiler produced faster code than the C benchmarks Tartan
used to convince people to buy their *C* compilers instead of using the
free one that TI shipped with their DSPs. An article in _Ada Letters_
described the features of Ada and C that allowed them to do better
optimization for Ada than for C.

There was also a case of a Tartan Ada compiler producing faster code
than hand-optimized assembler. This was described in a TRI-Ada
presentation. The people developing the Ada made no special effort to
make the code fast, because the purpose of the project was to prove that
Ada was NOT fast enough. The project failed, sort of like the Tuskegee
Airman project.

In general, using modern compilers and modern processors, equivalent
programs will produce equivalent execution times.

--
Jeffrey Carter

Re: Numerical Computation and Ada95

[Laurent Guerby]

"N&J" <nikogian@hotmail.com> writes:

> I have posed the question whether Ada95 is suitable for numerical
> programming at the newsgroup of numerical analysis.  I asked if
> Ada95 is better that Fortran90/95 and C++ for writing programs for
> numerical computation and the reply was that the Ada language
> specification requires extensive run-time checks which slows down
> the programs.

You can selectively turns checks off in Ada using language feature,
the information you have just shows that the people you've talked to
know nothing about Ada.

> I thought it would be better to ask your opinion too.

Wise :).

> I have noticed that there are too few numerical programs in Ada95
> for numerical computation is the above fact the real cause for this?

There is some numerical code available in Ada on the web, plus
bindings to traditional computing kernels. Most big Ada software is
for military or industry which is not widely known and distributed (as
opposed to Fortran in the scientific community).

> Finally would you suggest someone to use Ada95 for numerical code?

At work we have 250 KSLOC of Ada 95 doing financial number crunching
on a variety of platforms (SGI O2000 64 procs, Linux clusters of
various size, Solaris, NT), and Ada definitely does the job fine.

We turned checks off on one tight loop to beat third party code in
performance, otherwise we prefer the safety of checks against a 10-20%
speed improvement.

-- 
Laurent Guerby <guerby@acm.org>

Re: Numerical Computation and Ada95

[Gary Scott]

As an F95 programmer, I don't think that for most applications the
performance difference between these languages will be significantly
different if you limit the code to easily optimizable constructs. 
However, it is my impression that Fortran compiler vendors have
traditionally been much more obsessed with performance issues and I'm
certain that the standards committee designs nearly everything
obsessively with performance issues in mind (i.e. not "expressivity" of
language constructs).  I would expect that the average Fortran compiler
will be slightly faster than the average Ada or C or C++ compiler. 
Given that there are somewhere between 6 and 10 different commercial
Fortran vendors for x86 alone, it shouldn't be difficult to find one
that wins at any particular spec test suite routine on that platform.

N&J wrote:
> 
> Hi all,
> From what you said I undestand that nobody has ever compared Ada's timing
> performance with Fortran77/90/95, C and C++ in programs that require lots of
> arithmetic and logical operations (perhaps FFT). I think I will try to do it
> when I learn Ada95 better
> 
> Thanks for your help,
> John
> 
> P.S I am still a student and I work for myself that's why I am always
> looking for new things

Re: Numerical Computation and Ada95

[Gary Scott]

Hi, 

tmoran@acm.org wrote:
> 
> >From what you said I undestand that nobody has ever compared Ada's timing
> >performance with Fortran77/90/95, C and C++ in programs that require lots
> >of arithmetic and logical operations (perhaps FFT).  I think I will try to
> >do it when I learn Ada95 better
>   There was a substantial comparison someplace (perhaps Ada Letters?)
> some time ago, but I don't remember just when.  Try looking in
> www.adapower.com, www.adahome.com, or www.adaic.org  A simple minded
> transliteration from one language to another can have pitfalls,
> accessing arrays in row-major vs column-major order being an example.
> When I went to translate an algorithm from "Numerical Recipes in
> Fortran" it became obvious during the translation to Ada that the
> Fortran version was doing some extra, wasted, iterations.  Do you want
> to compare the Fortran version against an exact translation that
> includes those wasted cycles, or against an Ada version that preserves
> the algorithm, but not the poor coding?  It's not always obvious
> what's the appropriate comparison.

In that case, I'd probably clean up the Fortran code first, then
translate it and do the comparison.  Poorly written code is just that. 
However, the optimization possibilities of the language and the quality
of the optimizer itself has a lot more to do with the differences in
typical code (and cache accesses and memory alignment, etc.).

Re: Numerical Computation and Ada95

[N&J]

Hi all,
First of all I would like to thank everyone for his/her help. From what you
said I understand that it is pointless to compare languages in their timing
efficiency. Anyway, I am convinced that Ada95 is suitable for numerical
computation and I am going to use her. I would also like to refer everyone
interested in the subject to:

Jan Verschelde: Algorithm 795: PHCpack: A general-purpose solver for
polynomial systems by homotopy continuation. ACM Transactions on
Mathematical Software 25(2): 251-276, 1999.

PHCpack is a large general purpose package which solves systems of
polynomial equations (using homotopy continuation methods). In this paper
the author explains why he chose Ada for writing this package

Re: Numerical Computation and Ada95

[DuckE]

"N&J" <nikogian@hotmail.com> wrote in message
news:9dc4sh$ru5$1@ulysses.noc.ntua.gr...
> Hi all,
> I have posed the question whether Ada95 is suitable for numerical
> programming at the newsgroup of numerical analysis.
> I asked if Ada95 is better that Fortran90/95 and C++ for writing programs
> for numerical computation and the reply was that the Ada language
> specification requires extensive
> run-time checks which slows down the programs. I thought it would be
better
> to ask your opinion too. I have noticed that there are too few numerical
> programs in Ada95 for numerical computation is the above fact the real
cause
> for this? Finally would you suggest someone to use Ada95 for numerical
code?
>
> Thanks,
> John
>
If the run time checks slow you down, most compilers allow you to turn them
off...

On the other hand if you're having problems that might be detected by run
time checks, will Fortran compilers allow you to turn checks on?

SteveD

Re: Numerical Computation and Ada95

[Lao Xiao Hai]

N&J wrote:

> Hi all,
> From what you said I undestand that nobody has ever compared Ada's timing
> performance with Fortran77/90/95, C and C++ in programs that require lots of
> arithmetic and logical operations (perhaps FFT).

I recently had a conversation with a person from Boeing who advised me that
their comparison study revealed the Ada compilers to be slower running a
set of benchmarks than code in C++.    I am told it is an internal document,
so I was unable to get access to it for my own tests.

Meanwhile, it is certainly the case that C++ and Fortran are not inherently
faster
than Ada.   In "Who Killed Roger Rabbit,"  the sensuous cartooned Lady named
Jessica says, "I'm not bad.  I'm just drawn that way."     Ada says, "I'm not
slow.
I'm just implemented that way."

Richard Riehle

Re: Numerical Computation and Ada95

[mike]

In article <3AFA9DC2.672CAFE9@fedelma.astro.univie.ac.at>,
stift@fedelma.astro.univie.ac.at says...
 
Dr Stift;

Thanks for the input, very valuable and interesting.

I would love to work in numerics using Ada, but the fact is that there
is no work in this field. Unless one is doing reasearch in a 
univ. or such place. Ada could be the best language ever for doing
numerical computation, but one can't find work with those skills.

It seems Java is making more headways into numerical computations. There
is much more interest in Java than Ada. Java now even is getting into 
real-time, an area which was reserved for languages like Ada and C.

Just checked http://www.dice.com and this is the result

Ada     =  357 positions
Java    =  13,794
C /C++  =  23,422

Then I typed 'Ada numerical' and got ONE position. Then typed
'java numerical' and got 15 positions. Then typed 'C numerical' and
got 64 positions. 

So, where are the jobs for someone who wants to do cool stuff like you
are working on? where is Ada used for numerical work? 

Mike

Re: Numerical Computation and Ada95

[Dan Nagle]

Hello,

Fortran pointers are more restricted than C pointers.

Fortran has pointer, target and allocatable attributes.
Allocatable objects are not aliased, and pointers are
simply aliases for targets or other pointers.  So the
objects which may be aliased form a distinct subset of
all objects in a procedure.

If the optimizer doesn't see pointer or target, all objects
are distinct.  Fortran has some other "no aliasing"
rules which together generally mean that the same optimizer
may operate more aggressively on Fortran code than C or C++
code.

I _think_ the optimizer may be nearly as aggressive compiling
Ada code, at least if it sees that no 'Access is present
in a procedure.  (My project to learn more about Ada keeps
getting delayed by work. :-( )

On 11 May 2001 06:58:21 -0500, Kilgallen@eisner.decus.org.nospam
(Larry Kilgallen) wrote:

>In article <3AFAF555.F534480E@lmtas.lmco.com>, Gary Scott <Gary.L.Scott@lmtas.lmco.com> writes:

<snip requoted>
>
>Whereas I was under the impression that the Fortran standard had recently
>added "pointer" constructs, the bane of optimization everywhere.


-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Re: Numerical Computation and Ada95

[Larry Kilgallen]

In article <3AFAF555.F534480E@lmtas.lmco.com>, Gary Scott <Gary.L.Scott@lmtas.lmco.com> writes:
> As an F95 programmer, I don't think that for most applications the
> performance difference between these languages will be significantly
> different if you limit the code to easily optimizable constructs. 
> However, it is my impression that Fortran compiler vendors have
> traditionally been much more obsessed with performance issues and I'm
> certain that the standards committee designs nearly everything
> obsessively with performance issues in mind (i.e. not "expressivity" of
> language constructs).

Whereas I was under the impression that the Fortran standard had recently
added "pointer" constructs, the bane of optimization everywhere.

Re: Numerical Computation and Ada95

[Marin David Condic]

I don't think that is entirely true. People have done timing comparisons,
but you absolutely must remember at all times that you are NOT comparing Ada
to Fortran and C/C++. What you are comparing is the relative speed of code
generated by two (or more) different COMPILERS. As others have observed,
since Fortran programmers tend to want highly optimized math operations, the
guys who write Fortran compilers tend to concentrate on this area. That
doesn't mean you won't discover that Fortran Compiler X produces slower code
than Ada Compiler Y. In point of fact, some Ada compilers are quite good at
optimizing math operations.

I think you would also find that the way Ada goes to such great pains to
precisely define the behavior of its mathematical types could be a major
help to you in developing your algorithms. Get hold of the Ada Reference
Manual and look at the definitions of the numeric types and the annexes that
relate to math and I think you'll be impressed with the facilities
available. (Sometimes it is a bit obscure, so be sure not to miss the parts
that talk about all of the attributes available for numeric types. Many are
extremely useful and aren't paralleled in other languages.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"N&J" <nikogian@hotmail.com> wrote in message
news:9dd9tb$1o56$1@ulysses.noc.ntua.gr...
> Hi all,
> From what you said I undestand that nobody has ever compared Ada's timing
> performance with Fortran77/90/95, C and C++ in programs that require lots
of
> arithmetic and logical operations (perhaps FFT). I think I will try to do
it
> when I learn Ada95 better
>
> Thanks for your help,
> John
>
> P.S I am still a student and I work for myself that's why I am always
> looking for new things
>
>

Re: Numerical Computation and Ada95

[Marin David Condic]

This just can't be said often enough. Languages (for the most part) aren't
fast or slow. Implementations are fast or slow. And even then, an
implementation may be fast with some things and slow with others. Its just
not possible to say "Ada is slower than Fortran at math" and it is very
damaging to make that claim . (What is it they say about Washington? If
three people repeat a statement there, it becomes a fact? The same thing
seems to apply to newsgroups.)

I like your analogy. Maybe to put this creature to rest we should write a
Fortran interpreter with every conceivable inefficiency built into it on
grounds of ease of implementation, then use this whenever someone brings up
the "Ada is slow" accusation. We can just say "Bring on your Fortran code
and we'll race!" :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:tdxK6.979$bi2.74527@www.newsranger.com...
> In article <9dd9tb$1o56$1@ulysses.noc.ntua.gr>, N&J says...
> Again, you *can't* make such a comparison. The best you can do is compare
> *implementations*, which have way more variables than just the source
language.
>
> Suppose I took my super-optimizing RTOS Ada compiler, compared it to the
> (mythical) $50 HappySoft Win95 Fortran compiler for students, and
discovered
> that Fortran was %50 *slower*. What exactly would I have proved? Only that
> HappySoft doesn't care about optimization as much as the authors of my Ada
> compiler.
>
> If you are wondering about *theory*, theoreticly Ada (with the checks
turned
> off) ought to be exactly the same speed for arithmetic and logical
operations as
> C, C++, and Fortran before optimization, and the same speed or *faster*
than any
> of them after optimization, due to the extra info that can be fed to the
> optimizer. But theory won't get you far in the Real World.

Re: Numerical Computation and Ada95

[Gary Scott]

Hi,

Larry Kilgallen wrote:
> 
> In article <3AFAF555.F534480E@lmtas.lmco.com>, Gary Scott <Gary.L.Scott@lmtas.lmco.com> writes:
> > As an F95 programmer, I don't think that for most applications the
> > performance difference between these languages will be significantly
> > different if you limit the code to easily optimizable constructs.
> > However, it is my impression that Fortran compiler vendors have
> > traditionally been much more obsessed with performance issues and I'm
> > certain that the standards committee designs nearly everything
> > obsessively with performance issues in mind (i.e. not "expressivity" of
> > language constructs).
> 
> Whereas I was under the impression that the Fortran standard had recently
> added "pointer" constructs, the bane of optimization everywhere.

Recent as in "pointers" were added a decade or so ago.  I would point
out also, that nearly every compiler supports "Cray" or "integer"
pointers as well which would likely inhibit optimization, however with
the addition of a standard pointer, the need for raw address pointers is
very limited (mixed language mostly, my only use is to use a win32 API
call to allocate a shared memory work space (file mapping) and
subsequently assign the starting address to a procedure variable).  The
next standard will (I think) add a new pointer specific to interfacing
with the C language.

Re: Numerical Computation and Ada95

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]


"N&J" <nikogian@hotmail.com> a �crit dans le message news: 9deus2$8t6$1@ulysses.noc.ntua.gr...
> Hi all,
> First of all I would like to thank everyone for his/her help. From what you
> said I understand that it is pointless to compare languages in their timing
> efficiency.
An other point I'm surprised nobody mentionned:
Provided your compiler supports Annex F, you get guarantees about the numerical accuracies of computations, *including* the accuracy
of the math library.
AFAIK, Fortran tells you nothing about the accuracy of sin, log, etc. So if you are concerned not only by fast results, but also by
accurate results, Ada is a big winner.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Numerical Computation and Ada95

[Marin David Condic]

I was afraid to say anything because its been so long since I regularly used
Fortran that I couldn't be sure that later versions of the language didn't
add features of which I was not aware. When I *was* a Fortran programmer and
started learning Ada, I was very impressed with the fact that Ada seemed to
have so much better support for math than did Fortran. (Aside from lack of
Log & trig at the time. :-) Certainly, Ada has added lots of new
mathematical capabilities in Ada95 only by now I don't know if Fortran has
caught up.

At the time, I was very impressed that Ada let you specify the accuracy you
required and/or check the accuracy that was available. Ada defined model
numbers and safe numbers that gave one a model for understanding how
calculations were going to be made & thus one could plan for it. Fortran
basically left the mechanics of the computations up to the machine with no
rigorous formal definition of behavior. (Or at least it was not nearly as
rigorous as the definition Ada provided.) Lots of this is a major aid in
numerical analysis when you're trying to figure out how good your
computations are going to be.

Now the numerous attributes available for numeric types as well as adding
support for decimal & modular types would have me claiming that there is
quite a bit more support in Ada for number crunching than one gets with
Fortran - but the last Fortran I used was Fortran77. If later versions have
caught up, I'd like to know about it, but I'd recommend that Fortran number
crunchers take a serious look at Ada's numeric support because they just
might find it to be superior. (That, and its hard to beat Generics for
building computations once & reusing them with different numeric types!)

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:9dh4ol$s9g$1@s1.read.news.oleane.net...
> An other point I'm surprised nobody mentionned:
> Provided your compiler supports Annex F, you get guarantees about the
numerical accuracies of computations, *including* the accuracy
> of the math library.
> AFAIK, Fortran tells you nothing about the accuracy of sin, log, etc. So
if you are concerned not only by fast results, but also by
> accurate results, Ada is a big winner.
>

Re: Re: Numerical Computation and Ada95

[Gautier de Montmollin]

> Hi all,
> First of all I would like to thank everyone for his/her help. From what you
> said I understand that it is pointless to compare languages in their timing
> efficiency.

In contrary, it is interesting to compare - of course you compare rather
the *compilers*...

The good surprise is that you can e.g. make a *generic* sparse matrix package 
whose instanciations run as fast as their Fortran 77 equivalents for various
precisions. 
I did compare on an Alpha server under OpenVMS, with Ada & F77 compilers from Compaq.
It required a bit of tuning before reaching the original, of course, since
I coded the sparse matrix type as an unconstrained record with arrays in it,
a thing a bit more "clothed" than the arrays passed the in F77 code.

I needed to use that code in a project programmed in Ada, so the question was either
to interface to the F77 code or to make an Ada version.
In global programmation time it was also a big benefit since I could use later the same
code with GNAT on e.g. PC platforms. If you use the correct switches, like
-O2, -gnatpn, -funroll-loops (GNAT), you obtain a very nice performance.
Things like ":=", "others=>" with big objects are poorly coded
by some Ada compilers, but otherwise the job is very well done; abstraction
often helps performance.

In addition, in the debugging phase, you compile with the checks ON and you find
lots of bugs about array bounds. This is also an absolute plus!
BTW, interesting to mention that translations from Fortran very often show latent
or undetected bugs like 0 index reached in an array meant to be on 1..N, etc.

__________________________________________
Gautier  --  http://www.diax.ch/users/gdm/

-- 
Posted from duba05h05-0.dplanet.ch [212.35.36.52] 
via Mailgate.ORG Server - http://www.Mailgate.ORG