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)

[Dr. Krishnan Chittur]

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

: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
: > The fact remains (and will for some time) that many scientific
: programmers
: > are scientists FIRST and programmers SECOND.  
........
: > 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.

Well said! ... I still have to find an environment that will allow
me to develop a GUI as simply as I can write Fortran Code to 
do calculations ... if there is one, please let me know.

There is this debate in the Chemical Engineering Community about
whether we should teach Fortran at all ... We are currently on the
side that says "yes" we should.  

More than Fortran itself, what we are trying to do is to teach
the elements of programming ... the idea that you should plan the
project, have an idea of what you want the program to do,
design the "structure" ... and then write the code ... when you
want to say "calculate the square root" ... find out if you need
to write the program or use something that is supplied by 
compiler or perhaps a set of callable routines written by someone
else ... 

In a programming course, students also learn how to develop a  
"set of routines" .. one problem is that at the time they are
learning to program, often they do not have the background
in math ... for example it is difficult at the freshman level
to have students attempt to write Fortran Code to solve say
linear algebraic problems ... 

Anyway ... Fortran is still around, will be around for 
a while ... students MUST know how to deal with it's
many strange properties ... 4 to 6 weeks exposing them
to elements of fortran 77 is worth the time ... 

Fortran 90 and F are I think a step in the right direction,
let's see how it develops ... 

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

[Area Industrial y Electromec�nica]

I agree with you completely

Jose Jimenez, msme

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'

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

[Gary L. Scott]

The problem of developing a GUI in Fortran is one of designing an
appropriate API for Fortran.  This used to be done quite commonly
(language-specific API bindings).  I have developed "graphical user
interfaces" in Fortran that were highly functional (a little slow, it
was 10 years ago) and very easy to develop because the API was designed
"appropriately".  The problem is really one of UNIX/Windows APIs being
"low-level" C-oriented APIs.  It is great that Fortran is being extended
in ways which allow it to be able to call other languages and APIs
designed for other languages, however, I shouldn't have to.  OS or
compiler vendors should supply language tailored API bindings.  It's
more work for them, but a lot less work for me, as an application
developer who just wants to produce a useful product without the hassle
of inter language communication which requires me to essentially know
two (or more) languages, usually one of which has an appalling syntax
that makes me cringe).  I vote for a reduction in complexity (the
K.I.S.S. principle) in the area of OS API calls from Fortran (or PASCAL
or COBOL or PL/1 or <insert legacy language here>. Is anybody
listening?  Come on, there's only 1500 or so WIN API calls, how much
work could that be...).

Jeffrey Templon wrote:

> pvanesch@vub.ac.be (Vanesch P.) writes:
>
> > I think this is an essential point.  FORTRAN is well-suited to do
> > calculations and hard-core scientific computation.  But more
> > complex structures (a GUI is program-wise a lot more complicated
> > than a scientific calculation) are not dealt too well with in
> > fortran I think.  I've seen this in the high-energy community.
> > Both elements are present there: complex software systems and
> > hard-core scientific computing.  Well, I've seen quite a mess
> > in the FORTRAN implementation (rather ad hoc) of the complicated
> > datastructures that had to be manipulated.  It would have been
> > much better done (and the tendency now is - finally - to switch
> > to things like C++) in a language suited for the task.
>
> I agree that there are problems that get too complex for Fortran, at
> least for Fortran-77.  I'm not sure these limitations apply to
> Fortran-90, given the appearance of derived types and allocatable
> arrays.
> Perhaps F90 is not enough, but I think C++ is not the answer for
> people who aren't professional programmers.  Ada looks like it might
> be easier for a normal human to work with and read, but I haven't
> spent
> much time playing with it.
>
>                                                 JAT

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

[Vanesch P.]

Dr. Krishnan Chittur (chitturk@email.uah.edu) wrote:
: Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:

: : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
: : > The fact remains (and will for some time) that many scientific
: : programmers
: : > are scientists FIRST and programmers SECOND.  
: ........
: : > 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.

: Well said! ... I still have to find an environment that will allow
: me to develop a GUI as simply as I can write Fortran Code to 
: do calculations ... if there is one, please let me know.

I think this is an essential point.  FORTRAN is well-suited to do
calculations and hard-core scientific computation.  But more 
complex structures (a GUI is program-wise a lot more complicated
than a scientific calculation) are not dealt too well with in
fortran I think.  I've seen this in the high-energy community.
Both elements are present there: complex software systems and
hard-core scientific computing.  Well, I've seen quite a mess
in the FORTRAN implementation (rather ad hoc) of the complicated
datastructures that had to be manipulated.  It would have been
much better done (and the tendency now is - finally - to switch
to things like C++) in a language suited for the task.

On the other hand, I've also seen the opposite.  A collegue of mine
wrote a MONSTER program in C++ to do some straightforward matrix
manipulations.  The graphical user interface launches tens and tens
of windows in which one can manipulate parameters, look at graphs etc...
He worked for almost a year on the thing.  He is a computer scientist,
btw, I'm not.  I'm an engineer and physicist.
It takes about 10 minutes to even start up the thing, getting your
X-terminal cluttered with all those windows.
I've done the same thing in F77, but with an ASCII steering file,
in about a month... and guess what ?  my program tackles systems 
he can't even dream of handling in just a few hours (his can't do it,
it just runs out of 1 GB swap space !!) I get a nice ASCII file
with my results. For smaller systems, my program is about 20 times
faster, with less memory, than his, on the same system.

I think every language has its uses.  FORTRAN is old and 
very elementary on the conceptual level.  For most modern
computing applications (graphics, process steering, multi-user
things etc) it is simply too elementary.
But for applications where these elementary concepts are
sufficient (such as scientific computing - which is usually
advanced on the scientific level and very simple on the 
computational level) it allows indeed to write a reasonably simple
program that behaves resonably well by someone who has some
reasonable knowledge of computers but is not a computer scientist, 
without involving a lot of abstract computer-think.

But if the project is too ambitious, and the abstract computer
think is really needed, well... I don't think it is a good idea
to do it in FORTRAN.


cheers,
Patrick.

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

[Jeffrey Templon]

pvanesch@vub.ac.be (Vanesch P.) writes:

> I think this is an essential point.  FORTRAN is well-suited to do
> calculations and hard-core scientific computation.  But more 
> complex structures (a GUI is program-wise a lot more complicated
> than a scientific calculation) are not dealt too well with in
> fortran I think.  I've seen this in the high-energy community.
> Both elements are present there: complex software systems and
> hard-core scientific computing.  Well, I've seen quite a mess
> in the FORTRAN implementation (rather ad hoc) of the complicated
> datastructures that had to be manipulated.  It would have been
> much better done (and the tendency now is - finally - to switch
> to things like C++) in a language suited for the task.

I agree that there are problems that get too complex for Fortran, at
least for Fortran-77.  I'm not sure these limitations apply to
Fortran-90, given the appearance of derived types and allocatable arrays.
Perhaps F90 is not enough, but I think C++ is not the answer for
people who aren't professional programmers.  Ada looks like it might
be easier for a normal human to work with and read, but I haven't spent
much time playing with it.

						JAT

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

[Rick Hawkins]

In article <5ve7c6$f4m$1@info.uah.edu>,
Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote:

>Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:
>
>: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
>: > The fact remains (and will for some time) that many scientific
>: programmers
>: > are scientists FIRST and programmers SECOND.  
>........
>: > 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.

>Well said! ... I still have to find an environment that will allow
>me to develop a GUI as simply as I can write Fortran Code to 
>do calculations ... if there is one, please let me know.

yes!!!  learning c++ after not using c for ten years took some work.
Fortran after 12 years didn't; I could sit back donw and code.

I'm not going to knock c++; it's wonderful for where it belongs.  But
for my fairly simple models that just need numbers pounded into
submission, and which won't be reused, Fortran is *much* easier, if for
no other reason than high-level I/O.  I was spending 2/3 of my time in
c++ either writing pieces builit into fortran, or looking for libraries
with the pieces.  I think I switched when i couldn't find a max(), and
couldn't figure out the single example of writing a function with
variable number of arguments (actually, i used smalltalk for a while in
between, but that's another story).

Also, the bit on needing to define new classes for array bounds
checking, rather than a compiler switch, was maddening . . .

rick
-- 
R E HAWKINS
rhawkins@iastate.edu

These opinions will not be those of ISU until they pay my retainer.

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

[Jenn-Ching Luo]

Gary L. Scott <scottg@flash.net> wrote in article
<341F22C2.C46CE5F4@flash.net>...
> The problem of developing a GUI in Fortran is one of designing an
> appropriate API for Fortran.  .....
> .................................................. 
>                                       however, I shouldn't have to.  OS
or
> compiler vendors should supply language tailored API bindings.  It's
> more work for them, but a lot less work for me, as an application
> developer who just wants to produce a useful product without the hassle
> of inter language
> 


Just like most of developers, I started programming Windows Applications in
C++ for a short period. I personal like to use Fortran, and I gave up C++
for Windows programming. There is no trouble and problem to call WIN API
from Fortran.

If compiler (i.e. Fortran) vendors can provide more info, examples, or
documents for programming Windows applications (not quick win) in Fortran,
that certainly may help Fortran programmers.



Jenn-Ching Luo
http://www.Equation.com/People/Luo.htm

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

[Gary L. Scott]

Jenn-Ching Luo wrote:

> Gary L. Scott <scottg@flash.net> wrote in article
> <341F22C2.C46CE5F4@flash.net>...
> > The problem of developing a GUI in Fortran is one of designing an
> > appropriate API for Fortran.  .....
> > ..................................................
> >                                       however, I shouldn't have to.
> OS
> or
> > compiler vendors should supply language tailored API bindings.  It's
>
> > more work for them, but a lot less work for me, as an application
> > developer who just wants to produce a useful product without the
> hassle
> > of inter language
> >
>
> Just like most of developers, I started programming Windows
> Applications in
> C++ for a short period. I personal like to use Fortran, and I gave up
> C++
> for Windows programming. There is no trouble and problem to call WIN
> API
> from Fortran.
>
> If compiler (i.e. Fortran) vendors can provide more info, examples, or
>
> documents for programming Windows applications (not quick win) in
> Fortran,
> that certainly may help Fortran programmers.
>
> Jenn-Ching Luo
> http://www.Equation.com/People/Luo.htm

This is highly dependent upon your compiler's support for extensions to
the standard call syntax.  If you're calling Windows APIs, you're
probably not programming in "standard compliant" Fortran (when you use
these extensions).  Some people don't mind or require this.  I prefer
the simpler call syntax of "standard" Fortran.

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

[Oleg Krivosheev]

Hi,

rhawkins@iastate.edu (Rick Hawkins) writes:

> 
> In article <5ve7c6$f4m$1@info.uah.edu>,
> Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote:
> 
> >Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote:
> >
> >: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article
> >: > The fact remains (and will for some time) that many scientific
> >: programmers
> >: > are scientists FIRST and programmers SECOND.  
> >........
> >: > 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.
> 
> >Well said! ... I still have to find an environment that will allow
> >me to develop a GUI as simply as I can write Fortran Code to 
> >do calculations ... if there is one, please let me know.
> 
> yes!!!  learning c++ after not using c for ten years took some work.
> Fortran after 12 years didn't; I could sit back donw and code.

well, if you're talking about F77, yes. FYI, there are already
F90 and F95 here. I doubt you can program in F95 without
learning - just as you did with C++.

> I'm not going to knock c++; it's wonderful for where it belongs.  But
> for my fairly simple models that just need numbers pounded into
> submission, and which won't be reused, Fortran is *much* easier, if for
> no other reason than high-level I/O.  I was spending 2/3 of my time in
> c++ either writing pieces builit into fortran, or looking for libraries
> with the pieces.  I think I switched when i couldn't find a max(), and
> couldn't figure out the single example of writing a function with
> variable number of arguments (actually, i used smalltalk for a while in
> between, but that's another story).

hmm...

cannot find max() in c++?
couldn't figure how to write function with variable numbers
of arguments?

there is something wrong with your C++ installation
or with your C/C++ book.

OK

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

[Rick Hawkins]

In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
Oleg Krivosheev  <kriol@fnal.gov> wrote:

>rhawkins@iastate.edu (Rick Hawkins) writes:

>> yes!!!  learning c++ after not using c for ten years took some work.
>> Fortran after 12 years didn't; I could sit back donw and code.

>well, if you're talking about F77, yes. FYI, there are already
>F90 and F95 here. I doubt you can program in F95 without
>learning - just as you did with C++.

I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20
back then.

>> I'm not going to knock c++; it's wonderful for where it belongs.  But
>> for my fairly simple models that just need numbers pounded into
>> submission, and which won't be reused, Fortran is *much* easier, if for
>> no other reason than high-level I/O.  I was spending 2/3 of my time in
>> c++ either writing pieces builit into fortran, or looking for libraries
>> with the pieces.  I think I switched when i couldn't find a max(), and
>> couldn't figure out the single example of writing a function with
>> variable number of arguments (actually, i used smalltalk for a while in
>> between, but that's another story).

>cannot find max() in c++?

I tried.  I looked.  I'm convinced it must be there, but . . .

>couldn't figure how to write function with variable numbers
>of arguments?

In the two books that I had, there was a single example, whihc managed
not to explain. I  wasn't just the issue of variable number of
arguments, but of arbitrarily large variable numbers 
(i wanted my max()!  :)


>there is something wrong with your C++ installation
>or with your C/C++ book.

I assume it's the books; the compiler was either DEC cc or gcc; i forget
now.

rick


-- 
R E HAWKINS
rhawkins@iastate.edu

These opinions will not be those of ISU until they pay my retainer.

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

[Oleg Krivosheev]

Hi, Rick


rhawkins@iastate.edu (Rick Hawkins) writes:

> 
> 
> In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
> Oleg Krivosheev  <kriol@fnal.gov> wrote:
> 
> >rhawkins@iastate.edu (Rick Hawkins) writes:
> 
> >> yes!!!  learning c++ after not using c for ten years took some work.
> >> Fortran after 12 years didn't; I could sit back donw and code.
> 
> >well, if you're talking about F77, yes. FYI, there are already
> >F90 and F95 here. I doubt you can program in F95 without
> >learning - just as you did with C++.
> 
> I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20
> back then.

well, that's exactly what i was asking about - there were NO
F90/F95 twelve years ago ! If you're using F90 now, you learned
it somehow. Either i misunderstood something or our claim

"> >> Fortran after 12 years didn't; I could sit back donw and code."

is wrong.

> >cannot find max() in c++?
> 
> I tried.  I looked.  I'm convinced it must be there, but . . .
> 
> >couldn't figure how to write function with variable numbers
> >of arguments?
> 
> In the two books that I had, there was a single example, whihc managed
> not to explain. I  wasn't just the issue of variable number of
> arguments, but of arbitrarily large variable numbers 
> (i wanted my max()!  :)

sorry, i have only min ;)

well, try example below for min with
arbitrary larger number of arguments. Hope it can help

#include <assert.h>
#include <stdio.h>
#include <stdarg.h>

double
dmin( int nofargs, ... ) {

  double res = 1.0e+38, arg;
  int j;
  va_list ap;
  
  assert( nofargs > 1 );

  va_start(ap, nofargs );

  for( j = 0; j < nofargs; ++j ) {
    arg=va_arg( ap, double );
    if ( arg < res ) {
      res = arg;
    }
  }
  va_end(ap);
  return res;
}

int
main( void ) {

  printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
  
  printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
  
  printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );

  return 0;
}


> >there is something wrong with your C++ installation
> >or with your C/C++ book.
> 
> I assume it's the books; the compiler was either DEC cc or gcc; i forget
> now.

code above works fine with gcc on Sparc/Solaris 2.5 box

regards

OK

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

[Gary L. Scott]

Oleg Krivosheev wrote:

> Hi, Rick
>
> rhawkins@iastate.edu (Rick Hawkins) writes:
>
> >
> >
> > In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
> > Oleg Krivosheev  <kriol@fnal.gov> wrote:
> >
> > >rhawkins@iastate.edu (Rick Hawkins) writes:
> >
> > >> yes!!!  learning c++ after not using c for ten years took some
> work.
> > >> Fortran after 12 years didn't; I could sit back donw and code.
> >
> > >well, if you're talking about F77, yes. FYI, there are already
> > >F90 and F95 here. I doubt you can program in F95 without
> > >learning - just as you did with C++.
> >
> > I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops
> 20
> > back then.
>
> well, that's exactly what i was asking about - there were NO
> F90/F95 twelve years ago ! If you're using F90 now, you learned
> it somehow. Either i misunderstood something or our claim
>
> "> >> Fortran after 12 years didn't; I could sit back donw and code."
>
> is wrong.

However, a very large percentage of Fortran 90 features (even some of
the new intrinsics) have been in some FORTRAN 77 compilers for
minicomputers as extensions since the late 70's/early 80's.  The main
exceptions being array syntax and "non-sequence" derived types.  So some
of us have had a long time to learn them.  I've used the following since
around 1981:

block do/end do (also for/end for, loop/end loop)
! comment
free form source (almost identical to the current standard)
variable # calling arguments (not F90/not keyword arguments/kinda messy)

"Purdue" bit manipulation intrinsics
direct physical memory address access ("Cray pointer" substitute?/not
F90)
; record separator
I'm sure others that I can't recall right now...

That's why I have such a hard time believing how long it took to get
some of them standardized and why some of them are still not in the
standard (but are rumored).

>
>
> > >cannot find max() in c++?
> >
> > I tried.  I looked.  I'm convinced it must be there, but . . .
> >
> > >couldn't figure how to write function with variable numbers
> > >of arguments?
> >
> > In the two books that I had, there was a single example, whihc
> managed
> > not to explain. I  wasn't just the issue of variable number of
> > arguments, but of arbitrarily large variable numbers
> > (i wanted my max()!  :)
>
> sorry, i have only min ;)
>
> well, try example below for min with
> arbitrary larger number of arguments. Hope it can help
>
> #include <assert.h>
> #include <stdio.h>
> #include <stdarg.h>
>
> double
> dmin( int nofargs, ... ) {
>
>   double res = 1.0e+38, arg;
>   int j;
>   va_list ap;
>
>   assert( nofargs > 1 );
>
>   va_start(ap, nofargs );
>
>   for( j = 0; j < nofargs; ++j ) {
>     arg=va_arg( ap, double );
>     if ( arg < res ) {
>       res = arg;
>     }
>   }
>   va_end(ap);
>   return res;
> }
>
> int
> main( void ) {
>
>   printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
>
>   printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
>
>   printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );
>
>   return 0;
> }
>
> > >there is something wrong with your C++ installation
> > >or with your C/C++ book.
> >
> > I assume it's the books; the compiler was either DEC cc or gcc; i
> forget
> > now.
>
> code above works fine with gcc on Sparc/Solaris 2.5 box
>
> regards
>
> OK

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

[Rick Hawkins]

In article <vi8oh5keyy1.fsf@drabble.fnal.gov>,
Oleg Krivosheev  <kriol@fnal.gov> wrote:

>Hi, Rick

hi

>rhawkins@iastate.edu (Rick Hawkins) writes:

>> In article <vi8k9ge42bw.fsf@drabble.fnal.gov>,
>> Oleg Krivosheev  <kriol@fnal.gov> wrote:

>> >rhawkins@iastate.edu (Rick Hawkins) writes:

>> >> yes!!!  learning c++ after not using c for ten years took some work.
>> >> Fortran after 12 years didn't; I could sit back donw and code.

>> >well, if you're talking about F77, yes. FYI, there are already
>> >F90 and F95 here. I doubt you can program in F95 without
>> >learning - just as you did with C++.

>> I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20
>> back then.

>well, that's exactly what i was asking about - there were NO
>F90/F95 twelve years ago ! If you're using F90 now, you learned
>it somehow. Either i misunderstood something or our claim

Back then I used F77 and almost F77 (seems to me that DEC FORTRAN on
TOPS 20 was somewhere between 66 and 77.  But hey, we had a
preproccessor fof this c++ thing :).   That was about 83-84.  I used
some c back then, too.

Rolling ahead to 95, learing c++ took work.  I recoded a summer's worth
of c++ and smalltalk to fortran 77 in a day and a half, not having
looked at fortran since 84.

Roll ahead to a couple of weeks ago, i picked up a F90 book, read a
couple of chapters, and am happily using lots of it.

>sorry, i have only min ;)

>
>well, try example below for min with
>arbitrary larger number of arguments. Hope it can help

I'm definitely saving this one.  Thanks.  There's a coupel of future
pojects that will need objects, which will probably mean some c++.
-- 
R E HAWKINS
rhawkins@iastate.edu

These opinions will not be those of ISU until they pay my retainer.

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

[Xingzeng Liu]

It should be known that C++ and C are totally different languages. I
think for every one, to learn C++ is much more difficult than to learn
others. If you can learn C, FORTRAN, or PASCAL with 2 weeks, then I
think to learn C++ at least needs you 1 month. And you still need more
than 1 month to practice it, to know the real style of C++. 

I use C++ for 5 years. I think C++ is a very good language. It is much
suitable to do large complex simulations. It is reported in CERN that
their large C++ simulation software (transfered from their original
FORTRAN code) is faster than FORTRAN code. 

But for some small problem, C++ is not so good. And the depency of the
non-standard library is also a big problem for C++. The super point in
C++ is their ability to reuse. And there are so many different library
of the basic object library. You may find you loss yourself when work in
another platform.  It is also very weak in numerical computation. So now
I try to use FORTRAN 90. In my point of view, the new features such as
Module, type etc. much improve the convenice in writing programs.

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

[Oleg Krivosheev]

Hi,

Constantine Antonovich: <const@orbotech.co.il> writes:

> 
> Oleg Krivosheev wrote:
> > 
> > [skipped]
> > 
> > sorry, i have only min ;)
> > 
> > well, try example below for min with
> > arbitrary larger number of arguments. Hope it can help
> > 
> > #include <assert.h>
> > #include <stdio.h>
> > #include <stdarg.h>
> > 
> > double
> > dmin( int nofargs, ... ) {
> > 
> >   double res = 1.0e+38, arg;
> >   int j;
> >   va_list ap;
> > 
> >   assert( nofargs > 1 );
> > 
> >   va_start(ap, nofargs );
> > 
> >   for( j = 0; j < nofargs; ++j ) {
> >     arg=va_arg( ap, double );
> >     if ( arg < res ) {
> >       res = arg;
> >     }
> >   }
> >   va_end(ap);
> >   return res;
> > }
> > 
> > int
> > main( void ) {
> > 
> >   printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
> > 
> >   printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
> > 
> >   printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );
> > 
> >   return 0;
> > }
> > 
> > [skipped]
> > 
>     OK, just to be pedantic, the previous  example shows very fine
> the  difference  between  fortran and  C    in computations. Since

gu ?

> min/max are  standard fortran functions, it  can be  supposed they
> are maximally   optimized  with no  regards  to   number  of their
> arguments (just because the compiler takes care of them).

well, FYI, being standard means only that - being standard.
Compiler is free to optimize or to insert 5min  loop
into min/max function.

>     In the  contrary,   in the example,  we  have overhead of  the
> arguments  number  evaluation 

sure...

if you know how do not evaluate number of arguments
for functions (not min/max in particular) with arbitrary
number of arguments, please share your knowledge with us.

> and overhead of  implementation (not
> necessarily    this   one,  generally   almost    any  non-trivial
> non-built-in operation has  some overhead -   there has been  some
> reason   to  add  into  C  libraries  memcpy,   memcmp  and so  on
> functions).

what do you mean "overhead"? Can you clarify ?

>     Using  C++ and not C, most  probably, I would try to implement
> the min function in the following way:
> 
> inline double min(double v1, double v2) {
>   return v1<v2 ? v1 : v2;
> }
> inline double min(double v1, double v2, double v3) {
>   double v=min(v1,v2); return v<v3 ? v : v3;
> }
> inline double min(double v1, double v2, double v3, double v4) {
>   double v=min(v1,v2,v3); return v<v4 ? v : v4;
> }
> inline double min(double v1, double v2, double v3, double v4, double v5)
> {
>   double v=min(v1,v2,v3,v4); return v<v5 ? v : v5;
> }

please, don't change the nature of the problem - Rick
was asking about min/max function with ARBITRARY
number of arguments.

>     Such  a way  doesn't seem elegant enough and it only  emulates
> arbitrary number

nope. it's not. If the problem is to provide function
which can handle arbitrary number of arguments,
it cannot be solved by providing function(s) which
can handle limited number of arguments. Try to reread
logic textbook next time.

>   started  on SunOS 5.5.1 SUNW,Ultra-2 produces
>     dmin: 3.04 seconds
>     overloaded min: 1.11 seconds
>   started on SunOS 5.5.1 SUNW,SPARCstation-4 produces:
>     dmin: 9.32 seconds
>     overloaded min: 4.89 seconds
> and compiled  with -O option with HP  C++  A.03.72; and started on
> HP-UX A.09.05 9000/715 produces:
>     dmin: 4.63 seconds
>     overloaded min: 1.58 seconds

well, you compare apples and oranges.

You provided solution for related but
another problem than Rick was asking for.

still, you know better way to handle
functions with arbitrary number of
arguments (using C++, templates, exceptions
whatever), please, share it with us.

OK

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

[const]

Oleg Krivosheev wrote:
> 
> [skipped]
> 
> sorry, i have only min ;)
> 
> well, try example below for min with
> arbitrary larger number of arguments. Hope it can help
> 
> #include <assert.h>
> #include <stdio.h>
> #include <stdarg.h>
> 
> double
> dmin( int nofargs, ... ) {
> 
>   double res = 1.0e+38, arg;
>   int j;
>   va_list ap;
> 
>   assert( nofargs > 1 );
> 
>   va_start(ap, nofargs );
> 
>   for( j = 0; j < nofargs; ++j ) {
>     arg=va_arg( ap, double );
>     if ( arg < res ) {
>       res = arg;
>     }
>   }
>   va_end(ap);
>   return res;
> }
> 
> int
> main( void ) {
> 
>   printf( "%e\n", dmin( 2, 1.0, 2.0 ) );
> 
>   printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) );
> 
>   printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) );
> 
>   return 0;
> }
> 
> [skipped]
> 
    OK, just to be pedantic, the previous  example shows very fine
the  difference  between  fortran and  C    in computations. Since
min/max are  standard fortran functions, it  can be  supposed they
are maximally   optimized  with no  regards  to   number  of their
arguments (just because the compiler takes care of them).
    In the  contrary,   in the example,  we  have overhead of  the
arguments  number  evaluation and overhead of  implementation (not
necessarily    this   one,  generally   almost    any  non-trivial
non-built-in operation has  some overhead -   there has been  some
reason   to  add  into  C  libraries  memcpy,   memcmp  and so  on
functions).
    Moreover the idea of such an implementation contains two great
places   to  make   bugs and definitely     any  user  of  such an
implementation will be  doing the bugs  endlessly. Firstly, it  is
the  programmer who should worry about  conformity of the declared
number of  arguments to the actual  one. In such cases, generally,
adding or  removing  actual arguments, people  tend   to forget to
correct the  declared number. Secondly,  there is no  way for type
checking and  for type conversions, usage  of 1 instead of  1.0 in
the arguments list will cause very nasty problems.
    Using  C++ and not C, most  probably, I would try to implement
the min function in the following way:

inline double min(double v1, double v2) {
  return v1<v2 ? v1 : v2;
}
inline double min(double v1, double v2, double v3) {
  double v=min(v1,v2); return v<v3 ? v : v3;
}
inline double min(double v1, double v2, double v3, double v4) {
  double v=min(v1,v2,v3); return v<v4 ? v : v4;
}
inline double min(double v1, double v2, double v3, double v4, double v5)
{
  double v=min(v1,v2,v3,v4); return v<v5 ? v : v5;
}
// and so on

    Such  a way  doesn't seem elegant enough and it only  emulates
arbitrary number of min-function arguments but it solves the types
and the  number-conformity problems.   Trying to  use  non-defined
min(huge-arguments-number),   a programmer  just gets  compilation
error and can easily extend the  set of his min-functions. And the
last but not least: the following example compiled with -O3 option
with Sparc C++ 4.2 patch 104631-03 and
  started  on SunOS 5.5.1 SUNW,Ultra-2 produces
    dmin: 3.04 seconds
    overloaded min: 1.11 seconds
  started on SunOS 5.5.1 SUNW,SPARCstation-4 produces:
    dmin: 9.32 seconds
    overloaded min: 4.89 seconds
and compiled  with -O option with HP  C++  A.03.72; and started on
HP-UX A.09.05 9000/715 produces:
    dmin: 4.63 seconds
    overloaded min: 1.58 seconds

#include <sys/times.h>
#include <limits.h>
#include <iostream.h>

extern double dmin(int, double, ...);
//------------------------------------------------------
inline double min(double v1, double v2) {
  return v1<v2 ? v1 : v2;
}
inline double min(double v1, double v2, double v3) {
  double v=min(v1,v2); return v<v3 ? v : v3;
}
inline double min(double v1, double v2,
		  double v3, double v4) {
  double v=min(v1,v2,v3); return v<v4 ? v : v4;
}
inline double min(double v1, double v2,
		  double v3, double v4, double v5) {
  double v=min(v1,v2,v3,v4); return v<v5 ? v : v5;
}
//------------------------------------------------------
int main(void) {
  struct tms ts;
  clock_t clk, start;
  unsigned loop_len=6000000;
  unsigned loop;
  double dummy=0;

  start=times(&ts);
  loop=loop_len;
  while (loop--)
    dummy=dmin(5,1.0,2.0,3.0,dummy,(double)loop);
  clk=times(&ts)-start;
  cout << "    dmin: "
       << double(clk)/CLK_TCK << " seconds" << endl;

  start=times(&ts);
  loop=loop_len;
  while (loop--)
    dummy=min(1.0,2.0,3.0,dummy,loop);
  clk=times(&ts)-start;
  cout << "    overloaded min: "
       << double(clk)/CLK_TCK << " seconds" << endl;

  return 0;
}
//------------------------------------------------------
#include <stdarg.h>

double dmin(int nofargs, double d, ...)  {
  va_list ap; va_start(ap,d);

  while (--nofargs) {
    double v=va_arg(ap,double);
    if (v<d)
      d=v;
  }

  va_end(ap); return d;
}
//-----------------------------------------------------
//                     End of File
//-----------------------------------------------------

//------------------------------------------------------------------
// Opinions expressed here are my own only
//
// Constantine Antonovich,               Tel.  : ++972-8-942-3819
// software engineer,                    Fax   : ++972-8-942-3955
// Orbotech Ltd., P.O.Box 215,           Email: const@orbotech.co.il
// Yavne 81102, Israel
//------------------------------------------------------------------