Oberon vs F-90 and my two questions 
Author Message
 Oberon vs F-90 and my two questions

Quote:
>argle bargle argle bargle argle bargle . The most prominent example is
>explicit dynamic memory _deallocation_, which is known to be dangerous
>and was therefore dropped from the Pascal/Modula/Oberon line.

How is explicit deallocation dangerous?  Personally, I've never had a
problem with it.  At first I was surprised that Oberon, which stressed
simplicity and putting more responsability on the programmer (thus
encouraging better programming), included garbage collection.  However,
given the elegence of the method I can see it's point.

However what are the dangers of dispose (dog)?

Dang, I erased the other thing I wanted to quote.  Basically it had to
do with MODULE System and it's importance for textual machine
independance.  However, last I heard fortran is only important for use
on Cray computers.  (The year was 1991 and I was taking LisP.  As an
easy language we finished it in half a semester, and the second half
was a rap session with the teacher about neat-o stuff in the computing
world.  We discussed Cray architecture, and how memory access took four
clock cycles and therefore pointers would be far too slow for any Cray.
Thus, Crays only use ForTran or other pointerless languages.)  Thus,
isn't it possible that ForTran doesn't need machine independance?

As always, a voice from the peanut gallery,
Mick Powers



Tue, 27 May 1997 22:29:12 GMT  
 Oberon vs F-90 and my two questions

Quote:

><stuff deleted>

>How is explicit deallocation dangerous?  <stuff deleted>

It always allows the possibility of memory leaks, which are rarely a problem
at the early testing portion of a code, but will bite you when the code sees
real use.  How many codes do you use which are written by others and crash
in mysterious ways?

Quote:
><stuff deleted>  However, last I heard ForTran is only important for use
>on Cray computers.  (The year was 1991 and I was taking LisP.  As an
>easy language we finished it in half a semester, and the second half
>was a rap session with the teacher about neat-o stuff in the computing
>world.  We discussed Cray architecture, and how memory access took four
>clock cycles and therefore pointers would be far too slow for any Cray.
>Thus, Crays only use ForTran or other pointerless languages.)  Thus,
>isn't it possible that ForTran doesn't need machine independance?

Either your memory is wrong, or your teacher did't properly communicate the
implications of his/her knowledge.

1.  While C, C++, and Ada (and other languages) have made some inroads
Fortran still remains important to a large fraction of the scientific and
engineering community including those that do not use Crays.  This is
primarilly due to libraries, but partly due to performance.  While the
performance ratio of Fortran relative to other popular languages may not be
as much in Fortran's advantage on other machines as it is on supercomputers
it still exists (less so with Ada than C or C++).  LISP is less popular now,
but Crays have also had LISP compilers, although I suspect that they didn't
perform as well (for typical LISP codes) as the Fortran compilers.  However,
at least one functional language, Sissal?, claims performance comparable to
Fortran on Crays.

2.  Do you count C or C++ as pointerless languages?  While I suspect that
Fortran is still {*filter*}, a lot of coding on Crays is done in those two
languages.

3.  While pointers can cause some optimization problems, as long as one
dimensional arrays are available in the language, and the coder knows how to
take advantage of that fact, a high degree of optimization for typical
scientific applications is possible even if the higher dimensional arrays
have to be constructed using pointers.  Problems occur if local analysis
cannot show that a pointer is not an alias for something else in the same
section of code, so that the compiler generates unnecessary reads and writes
and cannot properly fill its pipeline.  This performance hit will be worse
for some machines than others, but it exists for all machines.  However,
special optimization techniques can often greatly reduce or eliminate this
performance hit, albeit with a compile time cost.  I have heard claims that
C and C++ compilers at their higher optimization levels do a lot of work to
deal with this problem by global optimization.

4.  Pointers of course are very useful and Fortran can be a language with
pointers.  One of the most popular extensions to versions of Fortran 77 were
called "Cray" pointers.  I suspect that they got their name because they
were first implemented in one of Cray's Fortran 77 compilers.  Cray
obviously felt that the existence of pointers had accetable effect on
optimization.  Fortran 90 has a different type of "pointer" from "Cray"
pointers, one which is typed and does not use pointer arithmetic, and it
appears to typically have negligible effect on performance.

5.  In a sense subprogram arguments in Fortran 77 (and usually in Fortran
90) are all pointers as they are passed by reference.  Fortran avoids the
aliasing problem with optimization by simply identifying it as a
programmer's error to use the same argument twice in the argument of a
subprogram or to pass as an argument an object that is part of a common
block used by the subprogram.  Of course ;-) it is not required by the ANSI
standard that the compiler detect this error.

6.  ANSI Fortran is very machine independent.  That is one of the biggest
complaints about it.  It is relatively easy to develop portable simple file
input/output code in any language, and that is about all ANSI Fortran 77
provides.  While good on numerics and performance, Fortran provides little
if any hooks to the machine or environment that allows the development of
flexible memory management, user friendly interfaces, etc.  Such hooks for
Fortran 77 typically have required nonportable extensions or vendor
libraries.  Further, its development environments have historically also
been minimal in many aspects, perhaps to ensure portability, or perhaps to
allow the compiler developers to concentrate on compiler efficiency,
extensions, and support.  This is not required by the language, but is very
typical.  Many of the extensions have been standardized by Fortran 90 to
allow portability with an increase in power by adding pointers, allocatable
arrays, bit data manipulations, etc.  Further this increase in complexity
has demanded an improved development environment so the environments have
been force to improve.  However Fortran still lacks the power of direct
access to most of the machine that C and Ada give, or the indiect access
through a standard environment that Oberon (typically) or Smalltalk give,
while the improvements in development environments have at best kept the gap
with respect to other languages from widening even further.

An aside:

A better expert may want to express his opinions on the next subject. In
another article it was noted that the author thought that Fortran compilers
did seven or eight passes in compiling a code, and that that implied that
Fortran compilers would therefore take an order of magnitude longer time.  I
don't have any statistics on that, but there is nothing in the language that
requires that many passes.  Fortran does require a minimum of two passes as
it places fewer restrictions on the order of its statements than a language
that allows the implementation of a one pass compiler.  However, it is not
just the number of passes but the amount of work that needs to be done on
each pass (and of course how efficiently that work is coded) that is
critical.  With a well written compiler ;-) I suspect that Oberon's
efficiencies can be achieved in two passes by a Fortran 90 compiler,
although, given the complexity of Fortran 90, those two passes combined
should take more time than Oberon's one pass.  Additional passes would be
needed for further optimization, but they would focus on selected
optimizations and should do less work per pass.  The compilation time need
not grow linearly with language size.  The discussion of Fortran 77
compilers in comp.sys.mac.scitech suggests that Fortran 77 can be compiled
with high optimization in time scales comparable to Oberon's single pass
compiler, and Fortran 77 with the extensions implemented by those compilers
is significantly larger (mostly due to variations on common extensions) than
Oberon.  



Wed, 28 May 1997 02:40:13 GMT  
 Oberon vs F-90 and my two questions


Quote:
>>argle bargle argle bargle argle bargle .

Hm... is your mailer OK ?

The most prominent example is

Quote:
>>explicit dynamic memory _deallocation_, which is known to be dangerous
>>and was therefore dropped from the Pascal/Modula/Oberon line.

> How is explicit deallocation dangerous?  Personally, I've never had a
> problem with it.  At first I was surprised that Oberon, which stressed
> simplicity and putting more responsability on the programmer (thus
> encouraging better programming), included garbage collection.  However,
> given the elegence of the method I can see it's point.

> However what are the dangers of dispose (dog)?

VAR dog1, dog2: ^dogType;
BEGIN NEW (dog1); dog2 := dog1; DISPOSE (dog1);
        (* here more allocations of other dynamic variables *)
      dog2^.SomeDataField := SomeData;
        (* here have fun looking at what happened to other dynamic variables *)
        (* here using other dynamic variables *)
      SomeOtherData :=  dog2^.SomeDataField;
        (* can you predict what SomeOtherData is? *)
END;

Quote:

> Dang, I erased the other thing I wanted to quote.  Basically it had to
> do with MODULE System and it's importance for textual machine
> independance.  However, last I heard ForTran is only important for use
> on Cray computers.  (The year was 1991 and I was taking LisP.  As an
> easy language we finished it in half a semester, and the second half
> was a rap session with the teacher about neat-o stuff in the computing
> world.  We discussed Cray architecture, and how memory access took four
> clock cycles and therefore pointers would be far too slow for any Cray.
> Thus, Crays only use ForTran or other pointerless languages.)  Thus,
> isn't it possible that ForTran doesn't need machine independance?

You mean MODULE SYSTEM, not System, right ?

I do not know where you have heard that "ForTran is only important for use
on Cray computers."? Was it during the LISP course ? Have you heard anything
about ForTran later on ? Maybe you did not look carefully enough at ads in
the BYTE magazine ? If you did you might have noticed some ads about non-Cray
Fortran compilers, like for example PC, Mac and possibly for other platforms?
I presume that having good machine independence in the second (after LISP)
most popular programming language on the planet is sort of important,
is it not ? Or maybe the third most popular, I will not argue about that.

Note I did not say f-90 is not machine independent. I hope that f-90
has addressed this problem, but I do not know how well since no compiler
is available anywhere near me. All that I said was a question about
why f-90 failed to _cleanly_ isolate machine issues under the SYSTEM module ?

Wojtek

Quote:
> As always, a voice from the peanut gallery,
> Mick Powers




Wed, 28 May 1997 11:38:32 GMT  
 Oberon vs F-90 and my two questions


Quote:
>>argle bargle argle bargle argle bargle . The most prominent example is
>>explicit dynamic memory _deallocation_, which is known to be dangerous
>>and was therefore dropped from the Pascal/Modula/Oberon line.

>How is explicit deallocation dangerous?  Personally, I've never had a
>problem with it.  At first I was surprised that Oberon, which stressed
>simplicity and putting more responsability on the programmer (thus
>encouraging better programming), included garbage collection.  However,
>given the elegence of the method I can see it's point.

>However what are the dangers of dispose (dog)?

You may have misinterpretted the comment here.  It's not dangerous in the
respect that the US Gov't will add it onto any legislation dealing with
gun control, but it is dangerous in the fact that you can have dangling
pointers, and orphaned memory blocks.

In theory, any program ought to be able to do all of its allocation and
deallocation manually (well, the programmer should be able to), but it
practice it is rarely the case.  Consider, for example, how many times a
Unix box has to be rebooted nowadays -- while I cannot attribute the
frequency directly to manual memory deallocation, it probably plays a
large factor.  I've also read an interview with some Microsoft employee
(In fact, I think it was in the MSDN, but not sure) which said MFC 2.0
has memory leaks.

The problem with explicit deallocation becomes even more important with
type extension and you never know to which type your pointer is really
referring.  In C++, you (virtually) must declare destructors as virtual
(if you are using pointers to the object), or memory deallocation _IS_
dangerous.

GC saves you from all of this danger.

[As a casual bystander, it always causes me to laugh at the dichotomy
exhibited in C++ programmers.  If you say (with the exception of
templates and exceptions) "You can do anything in C which you can do in
C++", the C++ proponent will say "Yes, but C++ gives you the ability in
the language.  You don't have to make all your vtables by hand and you
don't have to... blah de blah yada yada yada".  But, if you tell them
about GC, their response is "I'd rather do it by hand."]

In C++, explicit deallocation is dangerous and, when it causes an error,
very very very hard to find.

Taylor Hutt, explicitly allocated by my parents
C++ := NIL;



Wed, 28 May 1997 23:25:30 GMT  
 Oberon vs F-90 and my two questions
Quote:
> Taylor Hutt, explicitly allocated by my parents

Will you be explicitly deallocated also, or will you be left to the
garbage collector?

Quote:
> C++ := NIL;

Don't do that. The GC will have a hard time organizing all the
garbage.

Gonzalo Travieso, unintentinally freed by the destructor.



Fri, 30 May 1997 21:59:29 GMT  
 Oberon vs F-90 and my two questions

Quote:

>> Taylor Hutt, explicitly allocated by my parents
> Will you be explicitly deallocated also, or will you be left to the
> garbage collector?

>> C++ := NIL;
> Don't do that. The GC will have a hard time organizing all the
> garbage.

> Gonzalo Travieso, unintentinally freed by the destructor.

Why do not we call destructors "terminators" ? Or "terminators-2",
for that matter ?

W.



Sat, 31 May 1997 01:58:19 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Oberon vs F-90

2. Oberon vs F-90

3. Oberon vs F-90

4. Return Receipt: Re: Oberon vs F-90

5. Oberon vs F-90

6. Oberon vs F-90

7. FS: Fortran 90 compilers for Windows 95/NT

8. Fortran 90 vs HPF vs Fortran D

9. Two Oberon questions

10. Structured return values (was: Two Oberon questions)

11. Getting a subset of a two dimensional array on fortran 90

12. Announcing two new Fortran 90/95 books

 

 
Powered by phpBB® Forum Software