Is Fortran faster than C? - Programming Languages

On 5 Jul, 21:21, James Harris <james.harri...@googlemail.com> wrote:[color=blue]
> On 4 Jul, 03:05, "Vista" <a...@gmai.com> wrote:
> ...
> ...(re. 128-bit reals in Fortran and C)
> ...
>[color=green]
> > If the consensus is that Fortran for numerical calculations is only 5%
> > faster than C/C++, then I won't bother turn to Fortran.[/color][/color]

Here is a link from the language shootout I mentioned. It shows
comparisons between a Fortran and a C implementation: <http://
shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
that is as close as possible to your intended app. It's not a panacea
but might go some way to answering the original question you posed.
It's not too clear but grey means C is faster.

The C code is almost universally quicker. If you have an implementaion
that supports the data type you want to use, then as they say, write
in C: <http://www.poppyfields.net/filks/00259.html>

Steve Lionel wrote:[color=blue]
> On Jul 4, 9:45 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>[color=green]
>> Only a few VAX models seem to have hardware support for H float,
>> the 11/730 was the first one I knew about.[/color]
>
> And if memory serves me correctly, the only one until the VAX 9000
> came out, though the 9000's H-float support was later partially gutted
> in order to better support packed decimal for COBOL.[/color]

I thought the 11/780 had an option, i.e., a hardware card that
plugged into the Masbus(?), that implemented H-float. Do I
misremember?

-Ken
--
Ken & Ann Fairfield
What: Ken dot And dot Ann
Where: Gmail dot Com

In article <1183673566.649269.73470@o61g2000hsh.googlegroups.com>,
James Harris <james.harris.1@googlemail.com> wrote:
[color=blue]
>Here is a link from the language shootout I mentioned. It shows
>comparisons between a Fortran and a C implementation: <http://
>shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
>that is as close as possible to your intended app.[/color]

.... he might also want to use a compiler better than a very early
version of g95. You'd have to go out of your way to try to make
this "comparison" less useful.

-- greg

Greg Lindahl wrote:[color=blue]
> In article <1183673566.649269.73470@o61g2000hsh.googlegroups.com>,
> James Harris <james.harris.1@googlemail.com> wrote:[color=green]
>> Here is a link from the language shootout I mentioned. It shows
>> comparisons between a Fortran and a C implementation: <http://
>> shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
>> that is as close as possible to your intended app.[/color]
>
> ... he might also want to use a compiler better than a very early
> version of g95. You'd have to go out of your way to try to make
> this "comparison" less useful.[/color]

Indeed.

It seems to me that, if one actually wants a language shootout, one
needs to at least make a token handwave at a reasonable statistical
test. That means taking a sampling of language implementations for each
language, timing the compilations of all of them, and comparing the
difference in the language averages to the variation within each
langauge to see if the results are actually statistically significant.

Given the very wide range of results reported for various Fortran
compilers in the Polyhedron test suite, I would be extremely surprised
to find any differences between C and Fortran that even began to
approach statistical significance, much less attained it.

At the very least, if one insists on trying to draw conclusions from a
single implementation in each language, one should at least compare
compilers with the same backend. The shootout results linked to above
compare g95 with a 4.0.1 GCC backend to a 4.1.2 version of GCC -- and
there was quite a lot of middle- and back-end optimization that happened
between those two GCC versions, which has nothing at all to do with
Fortran versus C.

- Brooks


--
The "bmoses-nospam" address is valid; no unmunging needed.

"Brooks Moses" <bmoses-nospam@cits1.stanford.edu> wrote in message
news:468D9FAB.2070807@cits1.stanford.edu...[color=blue]
> Greg Lindahl wrote:[color=green]
>> In article <1183673566.649269.73470@o61g2000hsh.googlegroups.com>,
>> James Harris <james.harris.1@googlemail.com> wrote:[color=darkred]
>>> Here is a link from the language shootout I mentioned. It shows
>>> comparisons between a Fortran and a C implementation: <http://
>>> shootout.alioth.debian.org/gp4/fortran.php>. Of course, pick a program
>>> that is as close as possible to your intended app.[/color]
>>
>> ... he might also want to use a compiler better than a very early
>> version of g95. You'd have to go out of your way to try to make
>> this "comparison" less useful.[/color]
>
> Indeed.
>
> It seems to me that, if one actually wants a language shootout, one needs
> to at least make a token handwave at a reasonable statistical test. That
> means taking a sampling of language implementations for each language,
> timing the compilations of all of them, and comparing the difference in
> the language averages to the variation within each langauge to see if the
> results are actually statistically significant.
>
> Given the very wide range of results reported for various Fortran
> compilers in the Polyhedron test suite, I would be extremely surprised to
> find any differences between C and Fortran that even began to approach
> statistical significance, much less attained it.
>
> At the very least, if one insists on trying to draw conclusions from a
> single implementation in each language, one should at least compare
> compilers with the same backend. The shootout results linked to above
> compare g95 with a 4.0.1 GCC backend to a 4.1.2 version of GCC -- and
> there was quite a lot of middle- and back-end optimization that happened
> between those two GCC versions, which has nothing at all to do with
> Fortran versus C.[/color]
I think it's funny how people look for speed in one blindingly-fast language
as opposed to another. You might think that it might come from the people
30 years ago for whom computing was a lot of time and money, but it's not.
It's usually asked by newcomers to a syntax.
--
Wade Ward

I can't think of a human problem that needs anywhere near 128 bits of
floating point.
Some integer problems I can believe do require absolute accuracy (e.g.
checking you really have found the factores of a very large integer or
for being prime. Also accountants count the very largest amounts in
the most worthless currencies down to the cents that only exist on
paper - even when the thousands denominated tokens are worthless tiny
impure metal objects.

There ARE problems where it is mportant to not lose so much
calculation precision as to not achieve the final objctive with any
accuracy. But as far as I know, all these problema can be resolved in
a way where an approximate solution, with variables being assigned
values which bear close relationship to the truth, allow moving the
starting point of the algorithm to this new startimg approximation and
making another calculation pass. (Normalization). The solutions
usually converge at a reasonable rate to the desired solution with any
desired degre of accureacy, if you proceed.

Wade Ward wrote:

(snip)
[color=blue]
> I think it's funny how people look for speed in one blindingly-fast language
> as opposed to another. You might think that it might come from the people
> 30 years ago for whom computing was a lot of time and money, but it's not.
> It's usually asked by newcomers to a syntax.[/color]

Even as computers get faster, people are more interested in fast
hardware and fast software then 20 or 30 years ago.

I keep noticing processors that are 10% faster than the
previous model by the same company.

20 or 30 years ago, a new processor would be at least twice
as fast or they wouldn't bother trying to sell it.

-- glen

Terence wrote:
[color=blue]
> I can't think of a human problem that needs anywhere near 128 bits of
> floating point.[/color]

(snip)
[color=blue]
> There ARE problems where it is mportant to not lose so much
> calculation precision as to not achieve the final objctive with any
> accuracy. But as far as I know, all these problema can be resolved in
> a way where an approximate solution, with variables being assigned
> values which bear close relationship to the truth, allow moving the
> starting point of the algorithm to this new startimg approximation and
> making another calculation pass. (Normalization). The solutions
> usually converge at a reasonable rate to the desired solution with any
> desired degre of accureacy, if you proceed.[/color]

Yes, those kind of problems. It might be possible to do other
ways, but sometimes high precision is the best way when you can't
be sure of another way. Or sometimes just to verify that the
other way does give the appropriately close answer.

-- glen

"Vista" <abc@gmai.com> writes:

[color=blue]
> If the consensus is that Fortran for numerical calculations is only 5%
> faster than C/C++, then I won't bother turn to Fortran.[/color]

This really depends on what you want to do. Fortran compilers
typically optimize for loops over large arrays, often employing loop
interchange, prefetching and blocking, which few (if any?) C/C++
compilers do. C++ can do some of the same optimisations by carefully
writing template libraries that instantiate code to specific array
sizes. I have heard of (at least) FFT and matrix multiply functions
made this way.

So, with good libraries, C++ may match Fortran on large array
operations, but if you need large-array code that isn't matched by an
existing optimized library, you might get more speed out of an
optimizing Fortran compiler.

For code that isn't dominated by loops over large arrays, I doubt
there is much speed difference between a good C/C++ compiler and a
good Fortran compiler.

You could also consider more modern languages like Clean, OCaml or
SML.

Torben