Is Fortran faster than C? - Programming Languages

Isaac Gouy wrote:[color=blue]
> Once upon a time the Haskell guys repeated the excuse that the
> shootout problems were designed to make C look good and make Haskell
> look bad, then along came some exceptionally awesome Haskell
> programmers who didn't see any reason why they couldn't write good
> programs for those problems.[/color]

Indeed, the benchmarks are so poorly designed that most can be completely
optimized away and what better language to do that than a lazy one?

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
[url]http://www.ffconsultancy.com/products/ocaml_journal/?usenet[/url]

Isaac Gouy wrote:[color=blue]
> Fortran in the benchmarks game is sadly unloved - no one's sending
> Features Requests asking for a different language implementation, no
> one's working on the programs ...
>
> [url]http://shootout.alioth.debian.org/gp4/faq.php#report[/url][/color]

Several people submitted improved Fortran code for the ray tracer benchmark
that was taken down.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
[url]http://www.ffconsultancy.com/products/ocaml_journal/?usenet[/url]

On Jul 7, 6:52 am, Jon Harrop <j...@ffconsultancy.com> wrote:[color=blue]
> Isaac Gouy wrote:[color=green]
> > Fortran in the benchmarks game is sadly unloved - no one's sending
> > Features Requests asking for a differentlanguageimplementation, no
> > one's working on the programs ...[/color]
>[color=green]
> >[url]http://shootout.alioth.debian.org/gp4/faq.php#report[/url][/color]
>
> Several people submitted improved Fortran code for the ray tracer benchmark
> that was taken down.[/color]


You make my point well - Fortran in the benchmarks game is sadly
unloved - that problem hasn't been shown for a couple of years.

[color=blue]
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet[/color]

Stephen Howe wrote:
[color=blue]
> One aspect where Fortran per se, has the edge over C, is that Fortran does
> not allow aliasing but C does.[/color]

I'm a biginning C programmer not familiar with this concept. In
the context of the above statement, can someone show an example
of "aliasing" in C (the sort which Fortran doesn't allow).

David Marsh <dmarsh@mail.com> wrote:
[color=blue]
> Stephen Howe wrote:
>[color=green]
> > One aspect where Fortran per se, has the edge over C, is that Fortran does
> > not allow aliasing but C does.[/color]
>
> I'm a biginning C programmer not familiar with this concept. In
> the context of the above statement, can someone show an example
> of "aliasing" in C (the sort which Fortran doesn't allow).[/color]

If you aren't familliar with the concept, odds are that you aren't
familliar with the Fortran rules related to it either. So I'll give a
Fortran example. (If I try to do it in C, I'll make a syntax error
unless I spend more time on it than I care to).

program maine
integer :: x(3,3)
read(*,*) x
call sub(x,x)
write (*,*) x
end program maine

subroutine sub(x,y)
integer :: x(3,3),y(3,3)
integer :: i,j
do i = 1 , 3
do j = 1 , 3
y(i,j) = x(j,i)
end do
end do
end subroutine sub

This code is invalid Fortran. The call to sub aliases the two dummy
arguments. Aliasing is ok in some cases (people fairly often get that
wrong, stating incorrectly that aliasing is disallowed in general).
However, this is one case where it is not allowed - because one of the
aliased arguments is defined in the subroutine.

Note that compilers are *NOT* required to catch this error; indeed most
compilers probably won't. (I made the subroutine external in a
deliberate attempt to decrease the odds of it getting caught). They will
probably just generate "incorrect" answers, where I have quoted the
"incorrect" because it is not defined what a correct answer would be. It
might be better for me to say that the answer will likely be surprising.

This is a junk example for many reasons. It is just something that was
trivial to throw together off the top of my head and would probably
illustrate wrong results from aliasing.

Basically, the standard says that aliasing in this case is not allowed
and the compiler may therefore compile code without needing to worry
about the possibility. This means that the compiler has more
opportunities for optimization... or one might even say that the
compiler doesn't have to pessimize. If the standard allowed code like
this, and made it give what some might think to be the expected answers,
the compiler might be forced to do something like make a temporary copy
of the arguments... at least if that is the expected behavior. In other
cases, that would not be the behavior people would expect.

I will not comment on the Fortran vs C aspects here. I consider that
flamewar material of the kind that I decline to get involved in. I am
replying solely to give an example of what illegal aliasing is in
Fortran. It is important to know this when programming in Fortran,
completely independent of any language comparison issues.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Isaac Gouy wrote:[color=blue]
> On Jul 7, 6:52 am, Jon Harrop <j...@ffconsultancy.com> wrote:[color=green]
>> Isaac Gouy wrote:[color=darkred]
>>> Fortran in the benchmarks game is sadly unloved - no one's sending
>>> Features Requests asking for a differentlanguageimplementation, no
>>> one's working on the programs ...
>>> [url]http://shootout.alioth.debian.org/gp4/faq.php#report[/url][/color]
>> Several people submitted improved Fortran code for the ray tracer benchmark
>> that was taken down.[/color]
>
>
> You make my point well - Fortran in the benchmarks game is sadly
> unloved - that problem hasn't been shown for a couple of years.[/color]

Maybe there are better things to do w/ their time????

--

David Marsh wrote:[color=blue]
>
> Stephen Howe wrote:
>[color=green]
> > One aspect where Fortran per se, has the edge over C, is that Fortran does
> > not allow aliasing but C does.[/color]
>
> I'm a biginning C programmer not familiar with this concept.[/color]

[url]http://en.wikipedia.org/wiki/Aliasing_%28computing%29[/url]

C evangelists like to pretend 'it doesn't really matter'. I've seen whole
chapters on C optimizations written by otherwise credible authors that totally
ignore the impacts of aliasing and side-effects on optimization. But it really
is a very important issue.
[color=blue]
> In
> the context of the above statement, can someone show an example
> of "aliasing" in C (the sort which Fortran doesn't allow).[/color]

Fortran allows 'aliasing' - but only when the programmer asserts that
it is wanted. E.g., via EQUIVALENCE in the olden days, and F90 pointers
in modern times. So the compiler is generally free to create optimal
code.

In C, things are the other way 'round. With its overuse of unrestricted
pointers for just about anything, data aliasing must very often be assumed,
whether it is there or not. This can seriously inhibit optimizations an
optimizer could otherwise make.

In my experience, few C programmers are aware of C99s 'restrict'
keyword. (Heck, most don't even know there is a C99...) Very few
understand where 'restrict' can be used and actually bother use it.
C++ has totally ignored the issue.

Yes there are often compiler flags to tell the compiler not to worry about
aliasing. But very often programs which are compiled this way stop working...

W.

Walter Spector wrote:[color=blue]
> David Marsh wrote:[color=green]
>> Stephen Howe wrote:
>>[color=darkred]
>>> One aspect where Fortran per se, has the edge over C, is that Fortran does
>>> not allow aliasing but C does.[/color]
>> I'm a biginning C programmer not familiar with this concept.[/color]
>
> [url]http://en.wikipedia.org/wiki/Aliasing_%28computing%29[/url]
>
> C evangelists like to pretend 'it doesn't really matter'. I've seen whole
> chapters on C optimizations written by otherwise credible authors that totally
> ignore the impacts of aliasing and side-effects on optimization. But it really
> is a very important issue.[/color]
Microsoft compatible C compilers have all aliasing related optimization
shut off by default, I suppose to spare their instructors from having to
cover the subject. Generally speaking, it is impossible for C compilers
to generate efficient code for arrays of arrays (nearest equivalent of
multiple dimensioned Fortran arrays) when these optimizations are
disabled. So, Walter is entirely correct about the importance of the
issue. It will bite the careless C or C++ programmer who uses gcc, for
example.
gcc will error out on violations when it is able to detect them. The
case ****ogous to the one Richard Maine showed for Fortran, however, is
entirely legal in C, and the compiler must not perform optimizations
which would break with aliasing.
Both C and Fortran aliasing rules were set in the first published
standards, but the Fortran standard has been around long enough (>40
years) for people to get used to it. C was not standardized until 18
years ago. As Walter says, the textbook authors have not all caught up.

dpb wrote:
[color=blue]
> Maybe there are better things to do w/ their time????[/color]

If your unfounded exageration was even slightly close to reality, the fact
that the entire community believes it is too much of a burden to present a
small piece of code which gives decent results... Well, that would speak
for itself.


Rui Maciel