Re: Java vs. Eiffel vs. C++ in realtime applications

Re: Java vs. Eiffel vs. C++ in realtime applications

[James Yang]

In article <34131554.73F2310E@roda.roc.servtech.com>,
Mike Roda  <mike@roda.roc.servtech.com> wrote:
>I would say C++ would have the edge right now for performance reasons
>even though Sun is coming out with some real-time extensions I think.  
>
>You gotta be kidding about fortran!  As the oldest high-level language
>in existance, it is archaic, primitive, and hard to find people who want
>to touch it anymore.
>
>And Ada is a overloaded school bus that nobody would have ever used if
>it weren't for the DOD pushing it on everyone.  Get real.
>

Mike,

Your statement about Ada tells us you know nothing about Task and
concurrent programming in Ada. I hope the people who use Ada would
share some lights for you.

Comp.Lang.Ada added to the following thread.

James


-- 
My employer and I work together in the office. Nevertheless,  
we never speak on each other's behalf in term of political issues.

Re: Java vs. Eiffel vs. C++ in realtime applications

[Mike Rubenstein]

"Igor Chudov @ home" <ichudov@algebra.com> wrote:

> 
> Brian Thomson <thomson@vnet.ibm.com> wrote:
> * Nick Leaton wrote:
> * > John Viega wrote:
> * > > Anyway, I know tons of mechanical engineers and other types of
> * > > engineers, and I can tell you that Fortran is still considered by many
> * > > people to be the only appropriate language for much of the work that
> * > > they do.
> * >
> * > But then, one always wonders how much experience most of them have with
> * > some of the better alternatives that are available.
> * >
> * 
> * Nick, John was right that the FORTRAN language has properties that
> * enable it to perform better than C++ in certain situations.  This is
> * particularly true for programs that manipulate large matrices, which is
> * a significant piece of what scientific programming is about.
> 
> Thank you for your interesting comments, Brian. I would like to argue
> that while it is easy to write inefficient code in C++, it is also
> possible to write code as efficient as in Fortran.
> 
> An example follows below.
> 
> * If I write a subroutine to manipulate matrices, its parameters in
> * C or C++ will probably be pointers to double.  In FORTRAN they would be
> * double precision arrays. 
> 
> That is not completely informative because internally, parameters of
> FORTRAN subroutines are passed by pointer also. So both in C++ and fortran
> we deal with pointers.
> 
> * The FORTRAN language specifies that if one of
> * those arrays is modified by the subroutine, it may not overlap any of
> * the other arguments or global data.  In compiler-speak it is
> * guaranteed not to be "aliased" with anything else used in the
> * subroutine.
> * 
> * This property may not sound like much, but it allows FORTRAN
> * optimizers to optimize more fully than is possible in C/C++.
> * Eg. if I write
> *      C[I] = A[I] + B[I]
> *      D[I] = A[I] - B[I]
> 
> Well, C++ has a good recipe to deal with this important problem. In
> C++, you can declare A and B to be "const" pointers to double and that
> would tell the compiler that A[i] abd B[i] can be reused after assigning
> C[I].
> 
> Like this:
> 
> void foo( double * C, double * D, 
>           const double * A, const double * B,
>           int N )
> {
>   for( int I = 0; I < N; I++ )
>     {
>       C[I] = A[I] + B[I];
>       D[I] = A[I] - B[I];
>     }
> }

Only if the compiler is broken.  Declaring A and B const does not tell
the compiler that the values cannot change -- it tells it that it
cannot change using that pointer, unless the pointer is cast to a
pointer to nonconst. 

In particular, the compiler may not assume that C is different from A.
It would be legal to call this function as
	
	double x[2] = { 1.0, 2.0 };
	foo(x, x, x, x, 2);


Michael M Rubenstein

Re: Java vs. Eiffel vs. C++ in realtime applications

[Ralph Paul]

Robert Dewar wrote:
> 
> Mike Roda (who I assume is a current or recent product of CS education says)
> 
> <<Mike Roda  <mike@roda.roc.servtech.com> wrote:
> >I would say C++ would have the edge right now for performance reasons
> >even though Sun is coming out with some real-time extensions I think.
> >
> >You gotta be kidding about fortran!  As the oldest high-level language
> >in existance, it is archaic, primitive, and hard to find people who want
> >to touch it anymore.
> >
> >And Ada is a overloaded school bus that nobody would have ever used if
> >it weren't for the DOD pushing it on everyone.  Get real.>>
> 
> The Ada nonsense is not unexpected, there are far too many faculty members
> around who know nothing about Ada spouting such junk. But the Fortran
> nonsense is surprising. Are we really teaching out students these kind
> of silly attitudes and misinformation?
> 
> I must say, the idea that French defence companies are using Ada because
> the US DoD is pushing it on them is most amusing -- *most* amusing :-) :-)
> (not to mention outfits like Reuters in London, or ....)

I think the Russians also started using Ada (:-)  during the cold war.
I am certain fairly that they really didn't care about the US DoD
mandate.
But then again C++ and Java are going to safe the day anytime now (:-).
At least that's what Sun, Microsoft have been promising us for 1.5 years
(:-) .
( Oh, last but not least let's just shove all those Fortran code out the
door.
  You would be surprised how few engineering companies/shops would still
be able
  to operate without them. (:-) )

Sorry couldn't resist this guys uninformed comments .

Regards,

Ralph Paul

Re: Java vs. Eiffel vs. C++ in realtime applications

[Fergus Henderson]

miker3@ix.netcom.com (Mike Rubenstein) writes:

>"Igor Chudov @ home" <ichudov@algebra.com> wrote:
>
>> Brian Thomson <thomson@vnet.ibm.com> wrote:
>> * The FORTRAN language specifies that if one of
>> * those arrays is modified by the subroutine, it may not overlap any of
>> * the other arguments or global data.  In compiler-speak it is
>> * guaranteed not to be "aliased" with anything else used in the
>> * subroutine.
>> * 
>> * This property may not sound like much, but it allows FORTRAN
>> * optimizers to optimize more fully than is possible in C/C++.
...
>> Well, C++ has a good recipe to deal with this important problem. In
>> C++, you can declare A and B to be "const" pointers to double and that
>> would tell the compiler that A[i] and B[i] can be reused after assigning
>> C[I].
>
>Only if the compiler is broken.  Declaring A and B const does not tell
>the compiler that the values cannot change -- it tells it that it
>cannot change using that pointer, unless the pointer is cast to a
>pointer to nonconst. 

Yes, `const' doesn't promise that things won't be aliased.
The next revision of the C standard, C9X, will have a new keyword
"restrict" for that purpose, although it will probably be at least
a few years before many C or C++ compilers really support it.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Java vs. Eiffel vs. C++ in realtime applications

[Volker Hetzer]

Mike Rubenstein wrote:
> 
> "Igor Chudov @ home" <ichudov@algebra.com> wrote:
> 
> >
> > Brian Thomson <thomson@vnet.ibm.com> wrote:
> > Like this:
> >
> > void foo( double * C, double * D,
> >           const double * A, const double * B,
> >           int N )
> > {
> >   for( int I = 0; I < N; I++ )
> >     {
> >       C[I] = A[I] + B[I];
> >       D[I] = A[I] - B[I];
> >     }
> > }
> 
> Only if the compiler is broken.  Declaring A and B const does not tell
> the compiler that the values cannot change -- it tells it that it
> cannot change using that pointer, unless the pointer is cast to a
> pointer to nonconst.
What about
void foo(vect<double> &C, vect<double> &D, 
         const vect<double> &A,
         const vect<double>&B) ?

Volker

Re: Java vs. Eiffel vs. C++ in realtime applications

[Robert Dewar]

Mike Roda (who I assume is a current or recent product of CS education says)

<<Mike Roda  <mike@roda.roc.servtech.com> wrote:
>I would say C++ would have the edge right now for performance reasons
>even though Sun is coming out with some real-time extensions I think.
>
>You gotta be kidding about fortran!  As the oldest high-level language
>in existance, it is archaic, primitive, and hard to find people who want
>to touch it anymore.
>
>And Ada is a overloaded school bus that nobody would have ever used if
>it weren't for the DOD pushing it on everyone.  Get real.>>


The Ada nonsense is not unexpected, there are far too many faculty members
around who know nothing about Ada spouting such junk. But the Fortran
nonsense is surprising. Are we really teaching out students these kind
of silly attitudes and misinformation?

I must say, the idea that French defence companies are using Ada because
the US DoD is pushing it on them is most amusing -- *most* amusing :-) :-)
(not to mention outfits like Reuters in London, or ....)

Re: Java vs. Eiffel vs. C++ in realtime applications

[Mike Rubenstein]

Volker Hetzer <hetzer.abg@sni.de> wrote:

> 
> Mike Rubenstein wrote:
> > 
> > "Igor Chudov @ home" <ichudov@algebra.com> wrote:
> > 
> > >
> > > Brian Thomson <thomson@vnet.ibm.com> wrote:
> > > Like this:
> > >
> > > void foo( double * C, double * D,
> > >           const double * A, const double * B,
> > >           int N )
> > > {
> > >   for( int I = 0; I < N; I++ )
> > >     {
> > >       C[I] = A[I] + B[I];
> > >       D[I] = A[I] - B[I];
> > >     }
> > > }
> > 
> > Only if the compiler is broken.  Declaring A and B const does not tell
> > the compiler that the values cannot change -- it tells it that it
> > cannot change using that pointer, unless the pointer is cast to a
> > pointer to nonconst.
> What about
> void foo(vect<double> &C, vect<double> &D, 
>          const vect<double> &A,
>          const vect<double>&B) ?

I don't know what vect is, so I'll assume you mean vector.

I don't see how that is any different.  The const still doesn't
guarantee that A or B won't be changed -- only that they won't be
changed using that reference.  At least I cannot find anything in the
draft that would preclude calling such a function with

	vector<double> x;
	// ...
	foo(x, x, x, x);


Michael M Rubenstein

Re: Java vs. Eiffel vs. C++ in realtime applications

[Mike Rubenstein]

[Moderator's note: This article is crossposted to many groups.  I have
added a Followup-to line directing followups to go by default to
comp.std.c++ only.  If you respond to this article, you should think
about what group(s) your response is appropriate for.  mha]

"Igor Chudov @ home" <ichudov@algebra.com> wrote:

> [to comp.std.c++ readers: please correct me if I am mistaken. Thanks - Igor]
> 
> miker3@ix.netcom.com (Mike Rubenstein) wrote:
> * "Igor Chudov @ home" <ichudov@algebra.com> wrote:
> * > * The FORTRAN language specifies that if one of
> * > * those arrays is modified by the subroutine, it may not overlap any of
> * > * the other arguments or global data.  In compiler-speak it is
> * > * guaranteed not to be "aliased" with anything else used in the
> * > * subroutine.
> * > * 
> * > * This property may not sound like much, but it allows FORTRAN
> * > * optimizers to optimize more fully than is possible in C/C++.
> * > * Eg. if I write
> * > *      C[I] = A[I] + B[I]
> * > *      D[I] = A[I] - B[I]
> * > 
> * > Well, C++ has a good recipe to deal with this important problem. In
> * > C++, you can declare A and B to be "const" pointers to double and that
> * > would tell the compiler that A[i] abd B[i] can be reused after assigning
> * > C[I].
> * > 
> * > Like this:
> * > 
> * > void foo( double * C, double * D, 
> * >           const double * A, const double * B,
> * >           int N )
> * > {
> * >   for( int I = 0; I < N; I++ )
> * >     {
> * >       C[I] = A[I] + B[I];
> * >       D[I] = A[I] - B[I];
> * >     }
> * > }
> * 
> * Only if the compiler is broken.  Declaring A and B const does not tell
> * the compiler that the values cannot change -- it tells it that it
> * cannot change using that pointer, unless the pointer is cast to a
> * pointer to nonconst. 
> * 
> * In particular, the compiler may not assume that C is different from A.
> * It would be legal to call this function as
> * 	
> * 	double x[2] = { 1.0, 2.0 };
> * 	foo(x, x, x, x, 2);
> 
> I disagree with your statement. The compiler is free to optimize
> accesses to objects through const references, and is free to assume that
> the referenced contents do not change. The following provision of the
> C++ Standard Draft (http://www.setech.com/c++access.html) specifically
> addresses this issue:
> 
> Draft> 3 A  pointer or reference to a cv-qualified type need not actually point
> Draft>   or refer to a cv-qualified object, but it is treated as if it does;  a
> Draft>   const-qualified access path cannot be used to modify an object even if
> Draft>   the object referenced is  a  non-const  object  and  can  be  modified
> Draft>   through some other access path.  [Note: cv-qualifiers are supported by
> Draft>   the type system so that  they  cannot  be  subverted  without  casting
> Draft>   (_expr.const.cast_).  ]
> Draft> 
> Draft> 4 Except that any class member declared mutable (_dcl.stc_) can be modi-
> Draft>   fied, any attempt  to  modify  a  const  object  during  its  lifetime
> Draft>   (_basic.life_) results in undefined behavior.
> Draft> 
> Draft> 5 [Example:
> Draft> 
> Draft>   _________________________
> Draft>   76)  There is no special provision for a decl-specifier-seq that lacks
> Draft>   a type-specifier or that has a type-specifier that only specifies  cv-
> Draft>   qualifiers.  The "implicit int" rule of C is no longer supported.
> Draft> 
> Draft>           const int ci = 3;  // cv-qualified (initialized as required)
> Draft>           ci = 4;            // ill-formed: attempt to modify const
> Draft>           int i = 2;         // not cv-qualified
> Draft>           const int* cip;    // pointer to const int
> Draft>           cip = &i;          // okay: cv-qualified access path to unqualified
> Draft>           *cip = 4;          // ill-formed: attempt to modify through ptr to const
> Draft>           int* ip;
> Draft>           ip = const_cast<int*>(cip); // cast needed to convert const int* to int*
> Draft>           *ip = 4;           // defined: *ip points to i, a non-const object
> Draft>           const int* ciq = new const int (3); // initialized as required
> Draft>           int* iq = const_cast<int*>(ciq);    // cast required
> Draft>           *iq = 4;           // undefined: modifies a const object
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Look here
> 
> The last line of the example shows us that we should not expect that
> modifications of const objects through non-const access paths would
> correctly change them.
> 
> To be sure of that *iq changes, we'd have to use a "volatile" qualifier
> to define ciq
> 
> const volatile int * ciq  = ... ... ...

OK.  You are mistaken.  Note that 3. specifically says

	a const-qualified access path cannot be used to modify an 
	object even if the object referenced is  a  non-const  object

	and  can  be  modified through some other access path.

That says you can't change the object using the const pointer, but you
can change it through a different one ("through some other access
path").

Look at the example again.  It shows a case in which an object that is
referenced by a const pointer is changed:

	// ...
	int i = 2;         // not cv-qualified
	const int* cip;    // pointer to const int
	cip = &i;          // okay: cv-qualified access path to
			   // unqualified
	// ...
	int* ip;
	ip = const_cast<int*>(cip); // cast needed to convert const 
			   // int* to int*
	*ip = 4;           // defined: *ip points to i, a non-const
			   // object

cip is a pointer to const, but the object it points to has been
changed.

Whether an object is const is determined by its definition, not by the
declaration of a pointer that is used to access it.

If an object is defined as const, the compiler may assume that it will
not change, even if you access it through a pointer to non-const.  If
an object is not defined as const, the compiler may not assume that it
will not change, even if you access it through a pointer to const.

Obviously, in the case of the function foo you gave, the compiler has
no way of determining (in general) whether the objects pointed to were
defined as const.

Michael M Rubenstein
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

Re: Java vs. Eiffel vs. C++ in realtime applications

[Valentin Bonnard]

[Note: followup set to comp.std.c++]

Igor Chudov @ home <ichudov@algebra.com> writes:

> [to comp.std.c++ readers: please correct me if I am mistaken. Thanks - Igor]

You are

> miker3@ix.netcom.com (Mike Rubenstein) wrote:
> * "Igor Chudov @ home" <ichudov@algebra.com> wrote:
> * > * The FORTRAN language specifies that if one of
> * > * those arrays is modified by the subroutine, it may not overlap any of
> * > * the other arguments or global data.  In compiler-speak it is
> * > * guaranteed not to be "aliased" with anything else used in the
> * > * subroutine.
> * > * 
> * > * This property may not sound like much, but it allows FORTRAN
> * > * optimizers to optimize more fully than is possible in C/C++.
> * > * Eg. if I write
> * > *      C[I] = A[I] + B[I]
> * > *      D[I] = A[I] - B[I]
> * > 
> * > Well, C++ has a good recipe to deal with this important problem. In
> * > C++, you can declare A and B to be "const" pointers to double and that
> * > would tell the compiler that A[i] abd B[i] can be reused after assigning
> * > C[I].
> * > 
> * > Like this:
> * > 
> * > void foo( double * C, double * D, 
> * >           const double * A, const double * B,
> * >           int N )
> * > {
> * >   for( int I = 0; I < N; I++ )
> * >     {
> * >       C[I] = A[I] + B[I];
> * >       D[I] = A[I] - B[I];
> * >     }
> * > }
> * 
> * Only if the compiler is broken.  Declaring A and B const does not tell
> * the compiler that the values cannot change -- it tells it that it
> * cannot change using that pointer, unless the pointer is cast to a
> * pointer to nonconst. 
> * 
> * In particular, the compiler may not assume that C is different from A.
> * It would be legal to call this function as
> * 	
> * 	double x[2] = { 1.0, 2.0 };
> * 	foo(x, x, x, x, 2);

You are correct; a pointer (or a reference) can be 'cv T*', in this 
case cv is the qualification of the view of a T, not of T itself.

int i;
const int* pi = &i;

Here we view a non-const int as a const int; i can change, but not 
trough '*pi = 4' (this statement is ill-formed).

> I disagree with your statement. The compiler is free to optimize
> accesses to objects through const references, and is free to assume that
> the referenced contents do not change. 

That's wrong

> The following provision of the
> C++ Standard Draft (http://www.setech.com/c++access.html) specifically
> addresses this issue:
> 
> Draft> 3 A  pointer or reference to a cv-qualified type need not actually
> Draft> point or refer to a cv-qualified object, but it is treated as if it
> Draft> does;  a const-qualified access path cannot be used to modify an
> Draft> object even if the object referenced is  a  non-const  object  and
> Draft> can  be  modified through some other access path.

It's clear that 'the object referenced' 'can be modified through some
other access path'

> Draft>   [Note: cv-qualifiers are supported by the type system so that
> Draft>   they  cannot  be  subverted  without  casting
> Draft>   (_expr.const.cast_).  ]

BTW, this note is a lie, as it has already been pointed out

> Draft> 4 Except that any class member declared mutable (_dcl.stc_) can be
> Draft> modi- fied, any attempt  to  modify  a  const  object  during  its
> Draft> lifetime (_basic.life_) results in undefined behavior.

This is about const objects, not a view of a const objects, so it's 
irrelevant here.

> Draft> 5 [Example:

[...]

> Draft>           const int* ciq = new const int (3);
// initialized as required
> Draft>           int* iq = const_cast<int*>(ciq);    
// cast required
> Draft>           *iq = 4;           
// undefined: modifies a const object
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Look here
> 
> The last line of the example shows us that we should not expect that
> modifications of const objects through non-const access paths would
> correctly change them.

You are right; it means that access to a const object can be optimised; 
example:

const int size = 100;

foo (&size);
b = size; // can compile as 'b = 100' directly, we know that foo 
          // didn't changed size through a const-casted pointer

> To be sure of that *iq changes, we'd have to use a "volatile" qualifier
> to define ciq
> 
> const volatile int * ciq  = ... ... ...

volatile or not, you don't have the right to change a const object (but 
if you have a magic to do so, then you are right, volatile means that 
const applies to the view, not the object)

A consequence of the way const works is that it offers no 
optimisations except for object of dynamic type const (in other 
words, declared const).

To have the optimisation, C9X has some keyword 'restrict' (I think, 
comp.std.c is the place to ask).

-- 

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Re: Java vs. Eiffel vs. C++ in realtime applications

[Paul Johnson]

In article <341644F2.763D@BZZvnet.ibm.com>, "Igor Chudov @ home"
<ichudov@algebra.com> writes

On the subject of array optimisations where a compiler knows that data
is non-aliased, and so optimises reads and writes:

>[I am wondering what can Eiffel offer for such optimizations.]

Its a good question.

Eiffel complicates things hugely for the optimizer by having all arrays
resizable.  This means that the ARRAY object just holds size information
and a reference to another object (typically of class SPECIAL) that
actually holds the information.  Since arrays are not defined as part of
the language, the most obvious implementation is a double-indirection
with a matching pair of procedure calls: the application calls
ARRAY.item, which calls SPECIAL.item.

However the compiler knows about ARRAY, and can optimise it.  The
obvious thing to do is to optimise the statement x := array.item(n) into
something like

   x = array->store[n]

If the same array is referred to repeatedly then the compiler can also
say

   l_store = array->store;

   x = l_store[n]
   y = l_store[n+1]

which is not far off the most efficient way to do it.  The only way to
do better would be to translate 'n' into a pointer into the middle of
the array and do pointer arithmetic.  Hmmm.  Tricky, but it might be
possible.

As for the optimisation of multiple reads and writes to the same
address, the compiler can be sure that the store of an array is not
aliased by another array because arrays never allow that.

This of course leaves the problem of aliased arrays.  If I wrote

   local
      foo: ARRAY[INTEGER];
      bar: ARRAY[INTEGER];

      !!foo.make (1, 10);
      bar := foo;

then not only could I write via the alised path, but I could also
trigger a redimension, and hence move the store.  So everything written
above goes out of the window unless the compiler can prove that the
array is not accessed via an alias.

Or you can just recode your matrix multipler in C.  In fact I'm planning
to do exactly that RSN.

Paul.

--------------------------------+---------------------------------
Paul Johnson                    | You are lost in a maze of twisty
Email: Paul@treetop.demon.co.uk | little standards, all different.
       paul.johnson@gecm.com    |

Re: Java vs. Eiffel vs. C++ in realtime applications

[Joachim Durchholz]

Igor Chudov @ home wrote:
> Well, C++ has a good recipe to deal with this important problem. In
> C++, you can declare A and B to be "const" pointers to double and that
> would tell the compiler that A[i] abd B[i] can be reused after
> assigning
> C[I].
> [I am wondering what can Eiffel offer for such optimizations.]

Such declarations exist. Just say "a = old a" in the routine's
postcondition. If a contains references, it is even possible (and easy)
to specify shallow or deep comparison, so the language has some
additional flexibility over just specifying a parameter const.

However, I don't know wether any Eiffel compiler is already
sophisticated enough to make use of such things. I believe other stuff
has been on the agenda until recently, like making dynamic dispatch as
efficient as C++ with mostly nonvirtual functions, and getting array
access efficient (standard Eiffel arrays are resizable, and every array
access goes through a function call which must be optimized away - lots
of work for a compiler, but highly programmer-friendly).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Java vs. Eiffel vs. C++ in realtime applications

[Pavel]

Igor Chudov @ home wrote:<skipped>

> void foo( double * C, double * D,
>           const double * A, const double * B,
>           int N )
> {
>   for( int I = 0; I < N; I++ )
>     {
>       C[I] = A[I] + B[I];
>       D[I] = A[I] - B[I];
>     }
> }
>
>
> * a FORTRAN optimizer knows that A and B cannot be modified by
> the
> * first assignment, and so it can reuse the already loaded
> values
> * of A[I] and B[I].
>
> .. and so does the C++ compiler in the example above.

Does it? Who can told it that C does not overlap A or B?

>       INTEGER K,IUNIT,NDAYS
>       real matr1(100,100), matr2(100,100), matr3(100,100)
>       DATA IUNIT /1/
>
>       do 1 iter = 1, 200
> C     ########################### so i set matr1 and matr2 to
> something
>         do 2 i = 1, 100
>           do 3 j = 1, 100
>             matr1(i,j) = i+j
>             matr2(i,j) = i-j
>  2        continue
>  3      continue
>
>        do 12 i = 1, 100
>           do 13 j = 1, 100
>             r = 0
>             do 14 k = 1, 100
>                r = r + matr1(i,k) * matr2(k,j)
>  12         continue
>             matr3(i,j) = r
>  13        continue
>  14      continue
>
>       STOP
>       END

Nobody worrying about efficiency works with matrices in this
manner in Fortran. General structure matrices are stored in
1-dimensional arrays by column from sixties. BTW It makes
Fortran matrix libraries so compatible and long living comaring
with such C++ classes as your SquareMatrix. Every Fortran
software may use the following matrix multiplying program (and
program from other package for other operation with general
matrices. For your SquareMatrix -- what if your customer wants
to do one more operation which is already implemented in other
package on some SqMtx?). This is an example. Because of
copyright considerations I cannot give here the subroutine for
general matrix multiplication I use (it is not mine, it has been
written several tens years ago and I had never reasons to write
my own!). The following subroutine is mine own and it implements
one very common matrix primitive R = R + transpose(A) * A where
A is M*N rectangular matrix and R is N*N symmetric matrix (so
only upper triangle of it is stored 'by column' as usual) in
usual Fortran manner. Try to beat it with your C++ compiler!
      SUBROUTINE MTSATA(A,R,M,N)
      IMPLICIT REAL*8(A-H,O-Z)
      DIMENSION A(1),R(1)
      IR=1
      IA1=0
      DO 3 J=1,N
      IA2=0
      DO 2 I=1,J
      DO 1 K=1,M
      R(IR)=R(IR)+A(IA1+K)*A(IA2+K)
    1 CONTINUE
      IR=IR+1
      IA2=IA2+M
    2 CONTINUE
      IA1=IA1+M
    3 CONTINUE
      RETURN
      END
Pavel

Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Jeffrey Templon]

"Igor Chudov @ home" <ichudov@algebra.com> writes:

> Brian Thomson <thomson@vnet.ibm.com> wrote:

> * a FORTRAN optimizer knows that A and B cannot be modified by the

 [ ... ]

> * In C++ there is no such guarantee (unless you supply one
> * outside the language via a #pragma), and it makes a noticeable
> * difference in these matrix algorithms that are a big part of
> * scientific programming.
> 
> Well, the programmer of a Matrix class has to know what he is doing.
> Making C++ code efficient may be harder than writing efficient fortran
> code, but it is not impossible.

This is a good point, but perhaps not in the way that Igor intended.
One of the main reasons I tend to push Fortran (or something similar,
like Ada or Python ... although maybe not everyone would see what
I mean by "similar" here ;-) is that with stuff like C++, you *do*
have to know what you are doing, or you will make a mess of it.
The fact remains (and will for some time) that many scientific programmers
are scientists FIRST and programmers SECOND.  Turning the average
physicist/programmer (at least in my field) loose with a C++ compiler
is like giving your car keys to your eight-year-old.  A few of
them would actually be able to drive, but most of them would cause
big damage trying.

So one of my reasons for Fortran still being around: you can write
a reasonable program which runs reasonably efficiently just by more
or less typing in an expression of a simple algorithm.  Fortran's "mental
model" of the computer is very simple.

						JAT

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[Joseph M. O'Leary]

Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
<m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>...
> One of the main reasons I tend to push Fortran (or something similar,
> like Ada or Python ... although maybe not everyone would see what
> I mean by "similar" here ;-) is that with stuff like C++, you *do*
> have to know what you are doing, or you will make a mess of it.
> The fact remains (and will for some time) that many scientific
programmers
> are scientists FIRST and programmers SECOND.  Turning the average
> physicist/programmer (at least in my field) loose with a C++ compiler
> is like giving your car keys to your eight-year-old.  A few of
> them would actually be able to drive, but most of them would cause
> big damage trying.
> 
> So one of my reasons for Fortran still being around: you can write
> a reasonable program which runs reasonably efficiently just by more
> or less typing in an expression of a simple algorithm.  Fortran's "mental
> model" of the computer is very simple.

I agree with you. I spent the first 4 years of my professional career
working a large scale VAX/VMS Over-the-Horizon Radar project that was
written almost totally in FORTRAN.  When I say large scale, I'm talking
about something that required 2 VAX 6000/430 mainframes and, employed about
70 or 80 concurrent processes

Then I spent about a year and a half working on a Visual C++/Windows NT
project that replaced a large portion of the older project -- mainly the UI
code.   The difference between the 2 software development styles was like
night and day.  In the old system, you had to know beforehand exactly how
much memory your app (or process) required.  It was all allocated when the
process started.  If you data outgrew that size, the process crashed. 

Also, since it was in FORTRAN, the code read like...well like BASIC.  It
was very easy to pick up and very straightforward.  All code paths were
very structured, hierarchical, and BIG.  (Huge).  I think we documented
very well what we did and wrote some very clean code.  We didn't try to
force old, procedural programming techniquest on to an object-oriented
langauge.  We accomplished the same task with probably less than one-third
as many lines of code as the FORTRAN.

Still, I don't envy the long-time FORTRAN programmer who has to switch from
maintaining the old code base to maintaining the new one, even if it is
much less code to look at.  It requires quite a philosophical shift.  

Joe O'

Re: Fortran vs C++ vs. etc (has little to do with realtime anymore)

[James F Cornwall]

Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:


: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
: <m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>...
: > One of the main reasons I tend to push Fortran (or something similar,
: > like Ada or Python ... although maybe not everyone would see what
: > I mean by "similar" here ;-) is that with stuff like C++, you *do*
: > have to know what you are doing, or you will make a mess of it.
: > The fact remains (and will for some time) that many scientific
: programmers
: > are scientists FIRST and programmers SECOND.  Turning the average
: > physicist/programmer (at least in my field) loose with a C++ compiler
: > is like giving your car keys to your eight-year-old.  A few of
: > them would actually be able to drive, but most of them would cause
: > big damage trying.
: > 
: > So one of my reasons for Fortran still being around: you can write
: > a reasonable program which runs reasonably efficiently just by more
: > or less typing in an expression of a simple algorithm.  Fortran's "mental
: > model" of the computer is very simple.

: I agree with you. I spent the first 4 years of my professional career
: working a large scale VAX/VMS Over-the-Horizon Radar project that was
: written almost totally in FORTRAN.  When I say large scale, I'm talking
: about something that required 2 VAX 6000/430 mainframes and, employed about
: 70 or 80 concurrent processes

Oh, God - I spent more time than I care to remember working on the 
OTH-B project, too.  My aspect was sending the ionospheric "weather" 
forecasts to your system (using an ancient Univac terminal protocol  
<U200> bastardized to talk to a VAX...).  Our code was a hodgepodge 
of Fortrans (IV, V, & 77) and assmbler code, much of it created by 
scientist/programmers as described above.

Given a choice between any flavor Fortran and any flavor of C, FORTRAN
wins hands down for me and my style of thinking.  The language does 
what it needs to do and still keeps things simple enough to be usable 
for those of us below the stratosphere.....

Just my $0.02 worth, YMMV.   :-)

Jim Cornwall
(ex-USAF, now working on groundwater modeling...Using Fortran!)

: Then I spent about a year and a half working on a Visual C++/Windows NT
: project that replaced a large portion of the older project -- mainly the UI
: code.   The difference between the 2 software development styles was like
: night and day.  In the old system, you had to know beforehand exactly how
: much memory your app (or process) required.  It was all allocated when the
: process started.  If you data outgrew that size, the process crashed. 

: Also, since it was in FORTRAN, the code read like...well like BASIC.  It
: was very easy to pick up and very straightforward.  All code paths were
: very structured, hierarchical, and BIG.  (Huge).  I think we documented
: very well what we did and wrote some very clean code.  We didn't try to
: force old, procedural programming techniquest on to an object-oriented
: langauge.  We accomplished the same task with probably less than one-third
: as many lines of code as the FORTRAN.

: Still, I don't envy the long-time FORTRAN programmer who has to switch from
: maintaining the old code base to maintaining the new one, even if it is
: much less code to look at.  It requires quite a philosophical shift.  

: Joe O'