Object-oriented Fortran vs. Ada 95?

Object-oriented Fortran vs. Ada 95?

[Thomas Koenig]

[Please not the crosspost to comp.lang.ada and comp.lang.fortran]

In comp.lang.fortran, danpop@mail.cern.ch (Dan Pop) wrote:

>Even if OO features will prove inexpensive to implement, is it worth
>adding features which are irrelevant to (at least) 99% of the Fortran
>user base?

Probably not.

Also, I'm not too sure how much such an OO Fortran would be different
from Ada 95.

If you compare Fortran 95 with Ada 95, what obstacles to high
performance do you see in Ada?  (And please, nobody say anything
about runtime checks this round, that's been beaten to death ;-)

Re: Object-oriented Fortran vs. Ada 95?

[Wclodius]

ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) wrote:
> <snip>
> If you compare Fortran 95 with Ada 95, what obstacles to high
> performance do you see in Ada?  (And please, nobody say anything
> about runtime checks this round, that's been beaten to death ;-)
>

The Ada experts will have their own, better informed, opinions, but as a
Fortran user that has at least looked at the Ada 95 spec I thought that I
should chip in my two cents.

1.  If you don't use the object oriented features of the language there
need not be any penalties for the presence of the object oriented features
in the language.  (Whether or not an Ada 95 compiler implements all the
optimizations an Ada 83 compiler implements, is another story.  I can, for
instance, imagine that an initial rease of an Ada 95 compiler might not
have all the optimiztions present in an 93 compiler.)  There may be a
small compile time penalty, and there will be a large increase in the
difficulty in implementing robust optimizing standard conforming
compilers.

2.  It appears that, as with some other recent object oriented languages,
Ada 95 has separated the inheritence and "subtyping" heirarchy.  This
should allow the use of inheritence for the incremental developement of
software, without necessarilly incuring the dispatch penalty of inherited
code associated with languages such as C++, which tie together the
inheritence and subtyping heirarchies.  However, I would prefer a
different mechanism for this separation.  (Indeed I would prefer a more
flexible polymorphism than strict subtyping, e.g., the "matching"
polymorphism of Kim Bruce's languages.)

3.  There should be a penalty in cases where subtyping is used, due to the
use of multiple dispatching requiring lookup tables.  As a relative
performance hit it might be greater than that of C++, because Ada does not
normally have the performance hit from aliasing that C++ does have.

4.  I have no opinion on the relative merit of Ada's generic modules vs.
C++'s templates.

William B. Clodius

Re: Object-oriented Fortran vs. Ada 95?

[Israel Gale]

In article <4gajp4$6aj@fg70.rz.uni-karlsruhe.de>
ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes: 

>  If you compare Fortran 95 with Ada 95, what obstacles to high
>  performance do you see in Ada?  

Fortran 95 fits naturally with HPF (High Performance Fortran), a set of
industry-standard extensions to enable execution in parallel across a
network.  Some Fortran 90/95 compilers already come with HPF.  Does Ada
have a standard parallel dialect?

-Israel Gale

Re: Object-oriented Fortran vs. Ada 95?

[Steve Lionel]

In article <w3l4tsmaq9k.fsf@wind.hpc.pko.dec.com>, gale@wind.hpc.pko.dec.com 
(Israel Gale) writes:
|>Fortran 95 fits naturally with HPF (High Performance Fortran), a set of
|>industry-standard extensions to enable execution in parallel across a
|>network.  Some Fortran 90/95 compilers already come with HPF.  Does Ada
|>have a standard parallel dialect?

Ada has had parallelism since the first iteration of the language, Ada 83.
Indeed, it was the first major language to implement multithread concepts
as a required part of the language.  So in this area it is well ahead of
Fortran and HPF.  Ada's "tasking", however, was not designed with high
performance as a goal but rather distributed processing of small tasks

-- 

Steve Lionel                      Mail: lionel@quark.enet.dec.com
Fortran Development               WWW:  http://www.digital.com/info/slionel.html
Digital Equipment Corporation     CompuServe: 75263,3001
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698             "Free advice is worth every cent"

For information on Digital Fortran 90, see http://www.digital.com/info/hpc/f90/

Re: Object-oriented Fortran vs. Ada 95?

[Ted Dennison]

Israel Gale wrote:
> 
> In article <4gajp4$6aj@fg70.rz.uni-karlsruhe.de>
> ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
> 
> >  If you compare Fortran 95 with Ada 95, what obstacles to high
> >  performance do you see in Ada?
> 
> Fortran 95 fits naturally with HPF (High Performance Fortran), a set of
> industry-standard extensions to enable execution in parallel across a
> network.  Some Fortran 90/95 compilers already come with HPF.  Does Ada
> have a standard parallel dialect?

Yup. The OLD version of Ada has tasking primitives not as a dialect, 
but as an integeral part of the language standard. The new version not
only has tasking, but optional support (in one of the standard's
annexes) for distributed programming.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Object-oriented Fortran vs. Ada 95?

[Sergio Gelato]

In article <312A5D68.1B7C@escmail.orl.mmc.com>,
Ted Dennison  <dennison@escmail.orl.mmc.com> wrote:
>Israel Gale wrote:

>> In article <4gajp4$6aj@fg70.rz.uni-karlsruhe.de>
>> ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:

>> >  If you compare Fortran 95 with Ada 95, what obstacles to high
>> >  performance do you see in Ada?

>> Fortran 95 fits naturally with HPF (High Performance Fortran), a set of
>> industry-standard extensions to enable execution in parallel across a
>> network.  Some Fortran 90/95 compilers already come with HPF.  Does Ada
>> have a standard parallel dialect?

>Yup. The OLD version of Ada has tasking primitives not as a dialect, 
>but as an integeral part of the language standard. The new version not
>only has tasking, but optional support (in one of the standard's
>annexes) for distributed programming.

That is very useful for explicit parallelism; but one of the points of
having HPF is precisely to relieve the user from having to specify in
too much detail exactly how the application is to be parallelized.
After all, what is optimal on one system may not be on another.

I'm not saying that Ada compilers cannot be taught the same tricks that
HPF tools use; but will there be a large enough market to entice HPF
developers to apply their technology to Ada as well as Fortran? The
supercomputing center I am using does not currently offer the option of
compiling Ada programs at all; by contrast, they have a rather wide choice
of HPF tools. That won't change unless a significant number of those
scientists and engineers who now use Fortran suddenly decide to learn
Ada; and the overwhelming majority have better things to do with their time,
or think they do. Nothing intrinsically wrong about the design of Ada,
a language I'd personally like to see in more widespread use; but inertia
alone is enough to ensure that Fortran will remain the language of choice
in this particular niche for some time to come.

This thread, however, was motivated by the question whether it is appropriate
to add full-fledged Object-Oriented features to Fortran. Unless there is a
clear need for OOP in conjunction with the kind of features HPF provides,
one can still argue "use Ada if you need OOP, Fortran if you need automatic
parallelism on good old arrays".

Speaking of Annex E to the Ada 95 standard (distributed processing):
is there a free/inexpensive implementation of that annex that will
work---reasonably efficiently, of course---with GNAT on an IBM SP2? 
I was depressed to see all those
  begin
    null;
  end;
in the body of the relevant package (s-rpc.adb) in the GNAT distribution...
Pointers to a more useful replacement will be gratefully received.
-- 
Sergio Gelato

Re: Object-oriented Fortran vs. Ada 95?

[Ted Dennison]

Sergio Gelato wrote:
> 
> This thread, however, was motivated by the question whether it is appropriate
> to add full-fledged Object-Oriented features to Fortran. Unless there is a
> clear need for OOP in conjunction with the kind of features HPF provides,
> one can still argue "use Ada if you need OOP, Fortran if you need automatic
> parallelism on good old arrays".
> 
Ahhh. Unfortunatly (for you Fortran guys) this thread was cossposted
into
the Ada newsgroup in mid-discussion, with no explanation of what HPF is.

(...slight pause while I check DejaNews...)

Ok. So we are talking about compiler features (usually a pre-compiler)
that distributes data and code across a massively parallel architecture 
system. Hmm...kinda interesting.

When an architecture (such as the SMP Vaxen or the Harris Nighthawk)
implements parallel processing at the OS level, I would expect my Ada
compiler to distribute my tasks to the various processors. When an
architecture (such as an array-processor like the Cray) implements
parallel processing at the machine instruction level, I would 
expect my (Ada) compiler to search for inherent parallelism in my
compiled code and optimize accordingly (No small task, I'm sure).

As for OOP, I think I'd have to agree with your argument. Fortran was
not designed with OOP in mind. Merrily tacking on features to the 
language when there isn't a desperate need for them will only hasten 
its decent into entropy. Better to let Fortran live (or die) as 
Fortran.

> Speaking of Annex E to the Ada 95 standard (distributed processing):
> is there a free/inexpensive implementation of that annex that will
> work---reasonably efficiently, of course---with GNAT on an IBM SP2?
> I was depressed to see all those
>   begin
>     null;
>   end;
> in the body of the relevant package (s-rpc.adb) in the GNAT distribution...
> Pointers to a more useful replacement will be gratefully received.

My suspicion is that it will reamain like that until someone who wants
it implements it themselves (or pays ACT to do it for them). Even
then it will probably only exist on the one platform. But if you are
really curious, you could always e-mail ACT at 
   mailto:report@gnat.com
They should be able to tell you if an implementation exists.

Of course, If Fortran supports it on the IBM SP2, you could always 
write the package in Fortran, and link s-rpc.adb to it with interface
pragmas. 

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

The future of Fortran

[Kent Paul Dolan]

Followups diverted only to comp.lang.fortran.

In article "Re: Object-oriented Fortran vs. Ada 95?"
<312B6418.27E7@escmail.orl.mmc.com>, Ted Dennison
<dennison@escmail.orl.mmc.com> wrote:

> As for OOP, I think I'd have to agree with your argument. Fortran was
> not designed with OOP in mind. Merrily tacking on features to the 
> language when there isn't a desperate need for them will only hasten 
> its decent into entropy. Better to let Fortran live (or die) as 
> Fortran.

As a person at one time credited with yelling loudly enough in
comp.lang.fortran that the Fortran8x committee made Fortran 90 a rich
upgrade of Fortran 77 rather than a meager one, I'll have to repeat what I
said then:  if a language doesn't keep up with modern programming
technology, all the inertia generated by all the dusty decks in the world
won't keep it alive, and then suddenly you have a new generation of
hardware with all those dusty decks uncompilable.

Do you remember how many generations of 1401 machine code emulators were
written and sold because the original source code was
uncompilable/unlocatable?  This is not the model of computing most math
intense programmers would want Fortran's future to emulate.  Math intense
programming tends not to want to run in emulation mode.

Kicking and screaming all the way, FORTRAN 77 gained modules, rich
parallel programming syntax, structured records, and a lot more,
attempting to catch Fortran up with Pascal and Ada, and in some ways
(array notation) surpass them.  The ability to express things Fortran
programmers had always been doing with clumsy work-arounds for the
language's lacks (commons of arrays of scalars where arrays of records
were meant, for example), simply and naturally in constructs now part of
an upwardly compatible language standard, is a win few Fortran 90
programmers would be willing to give back, I'd bet.

Thinking "we never use OOP, why do we need it in Fortran" is probably
wrong-headed.  I was, and I'm sure many other Fortran programmers were,
conceptually creating abstract data types decades before OOP gave
programmers clean facilities for that purpose, and a vocabulary of
"objects" with which to talk about it; just in self defense to survive the
problem of programming in the large.

Adding those conceptual, implicit OOP "tricks" to become concrete,
explicit features of the language can only assist Fortran's survival into
the third millennium, and improve the vocabulary math intensive
programmers use to express to one another how they "package stuff up" to
make big programming projects mesh.

Like the Fortran 8x standards committee, the Fortran 9x committee will
have its crowd of naysayers, its herd of compiler vendors bellowing for
"only minimal editorial corrections in an otherwise perfect standard",
freely translated as "we want to milk our current cash cow product for
another decade without substantial new programming investment".  These
forces should be resisted, for the sake of Fortran, and the best models of
OOP should be consulted for the difficult task of designing an upwardly
compatible OOP extension of the Fortran 90 standard.

[Those of you who were around for my previous tirade will notice that I've
mellowed a lot in the last decade.  Starting a second family late in life
will do that to you; it's hard to get emotional when it's all you can do
to stay awake.  Two AM feedings are the pits.  One kid in grad school at
UNC, he'll teach English, one married with a kid of his own, one a
freshwoman at W&M, and one seven weeks old today.  Sheesh!]

-- 
Xanthian.                  | "..want the consequences of what you want.." | 
Kent, the man from xanth.  |        Neil A. Maxwell, LDS Apostle          |
Kent Paul Dolan            ------------------------------------------------
xanthian@{well,qualcomm}.com     Jobhunting?  Check www.qualcomm.com!

Re: Object-oriented Fortran vs. Ada 95?

[Rick Lutowski]

gelato@oort.ap.sissa.it (Sergio Gelato) wrote:
>
>This thread, however, was motivated by the question whether it is appropriate
>to add full-fledged Object-Oriented features to Fortran. Unless there is a
>clear need for OOP in conjunction with the kind of features HPF provides,
>one can still argue "use Ada if you need OOP, Fortran if you need automatic
>parallelism on good old arrays".

These are orthoganal issues; it is not a case of either-or.  If you
have a computationally-oriented problem, you will want "automatic
>parallelism on good old arrays".  If you want ease of maintenance
of your code, you will want certain OO features.  If you want your
computationally-oriented code to be highly maintainable, you will 
want both.  If you want neither, you want C;-)

Yes, there is a need for some (but not all) OO featues in Fortran.

Rick Lutowski
-- 
+-----------------------------------------------------------------+
|  Rick Lutowski       oa@iah.com                   713-332-7281  |
|  Object Access       http://www.iah.com/oa/       713-554-7617  |
| --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- |
|  The source for Programmer's Reusable Libraries (TM)     oa=OO  |
+-----------------------------------------------------------------+