Re: Starting to doubt fortran

Gordon Sande wrote:
Yes. Interestingly the code was writen as an exercise in exposition
with efficiency as a secondary objective. The resulting style meant
that there were absolutely no "clever" tricks. The efficiency turned
out to be first rate as well. Some codes that pay attention to small
cache sizes have come in and out of fashion over time. Caches were not
an issue in 1966 and the typical machine used by crystallographers is
not throttled by small caches, although that may be changing.

Actually I'm much more impressed by what people were able to get out of
their computers at that time, or even in the 80's, than I am with what
is achieved with current hardware/software combinations, and that can
only be the software writers to blame.


The story I have heard repeatedly is that C needs to be "updated" every
time a new version of the vendors C compiler comes out. I have always
understood that to be overly "clever" code although some claim that C
encourages such behaviour.

Actually that specific language happens to be a central part of my
experience in that particular area. In pre-standard C days, the story
was partly true, but mostly it was about finding out which header files
to include on the "new" platform. That tended to reflect how the vendor
organized these files. The C code itself was mostly acceptable to the
compiler though, in fact much more than when feeding the same piece of
Fortran code to two different compilers.

These issues were best solved by just expanding on the customary section
of #include's at the top of each C file, controlling the selections
using #ifdef's. Since the C preprosessor _is_ in fact a central part of
the C language standard (as opposed to using a preprocessor with
Fortran), it could be reliably depended upon in a portable way. (The
"updated" code would still compile on the previus platform(s) it had
been adapted.) In post-standardization days much of this has gone away,
I think.

But then there are some specific issues, firstly the habit programmers
have of making assumptions about things that they shouldn't, like the
size of the 'int' type for instance. Bugs related to this I remember
were quite common at the time when many computers and compilers
transitioned from the 8/16-bit world into the 32-bit world. This is not
really a language issue, but more a coding issue. In theory the same
issues are inherent with Fortran too, but probably C was the candidate
most likely to come across it as it usually is preferred over Fortran
when doing things on a low level close to the metal. ;-)

Most vendors also extend the set of libraries to provide lower-level
access to the system. That's beyond the standard, but many tend to be so
consistent that they could be thought of as a de facto standard (the
functions open/close as opposed to the standardized fopen/close for
example). But at this level one can also come across anoying differences.

--
-+-Ben-+-
.

Relevant Pages

  • Re: Bugs at my web site
    ... >> I don't think it's being maintained now, but given that Fortran 77 isn't ... >what might prove fatal with a new compiler. ... >that I think they are good traditional fortran, whatever some standard might ... guess at heart I'm still a scientist rather than a Real Programmer :-) ...
    (comp.lang.fortran)
  • Re: Bugs at my web site
    ... what might prove fatal with a new compiler. ... that I think they are good traditional fortran, whatever some standard might ... I hope the g95 people, after taking a good long vacation to ...
    (comp.lang.fortran)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... Your compiler supports SIZEOF as do several others including my ... to be other than 8bits when cheap memory came on the scene and BURIED ...
    (comp.lang.fortran)
  • Re: g77 compliance?
    ... > claims that code conforms to a standard doesn't mean that it actually ... I must admit i'm not the biggest fan of Fortran. ... > your experience leads you to suspect compiler conformance as a first ...
    (comp.lang.fortran)
  • Re: collection class performance seems SLOOOWWWWWW
    ... If the compiler is clever enough to know that ... The problem is actually I am comparing C# with FORTRAN. ... The bottleneck was in this code loop. ...
    (microsoft.public.dotnet.languages.csharp)