Is Fortran faster than C? - Programming Languages

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:f7Xii.276023$p47.273675@bgtnsc04-news.ops.worldnet.att.net...[color=blue]
> Wade Ward wrote:[color=green]
>> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
>> news:MlUii.145683$Sa4.12449@bgtnsc05-news.ops.worldnet.att.net...[color=darkred]
>>> Gary Scott wrote:
>>>> Mike wrote:[/color]
>>[color=darkred]
>>>> ...at the expense of "language expressiveness and flexibility"...
>>> C's expressiveness and flexibility are dubious qualities at best.[/color]
>> snip[color=darkred]
>>> If you want the flexibility to do string assignment, string
>>> concatenation, or extract substrings without using a clumsy function
>>> call syntax, C doesn't have that. Indeed, the only additional
>>> "flexibility" that
>>> C strings have is the increased likelyhood of buffer overruns.[/color]
>> I'm not sure what you mean. This sounds like K&R stuff, which I
>> thought everyone basically liked. I must say, with the few
>> concatenation's I've done in fortran, that the syntax was immediate.[/color]
>
> I find pretty much nothing in K&R to like. But then, I've always
> been more impressed by objective evidence of quality than by
> popularity. There's always seemed to be an anticorrelation
> between popularity and quality. In any case, the ability to
> write simply:
>
> my_str = a_str(1:5) // "stuff"
>
> is very convenient. The C equivalent is a set of nested function
> calls much less legible. And unless you're very careful indeed,
> the result of the concatenate may be longer than the space allotted
> for the result - but C intrinsics don't care and go ahead and wipe
> out whatever follows the result variable in memory. The Fortran
> statement above doesn't have those problems.[/color]
I see. Since I'm relatively new to fortran, I'm not mature in my ability to
work with strings, but don't get me wrong, when I left C for Fortran, I
burned my ships and don't regret it.
--
WW

Tim Prince wrote:

(snip on 128 bit floating point)
[color=blue]
> I believe the add/subtract/multiply emulation can be expanded in line.[/color]

I have the three book set from Intel, but I only have one out now.
[color=blue]
> Divide/sqrt clearly must be function calls (quite slow).[/color]

It seems like even single and double divide are multiple
instructions long, but probably are still done inline.
[color=blue]
> Single
> instruction floating point operations are 82 bits wide, so it requires
> combinations to extend to 128 bits. 80-bit mode should be at least
> twice as fast as 128-bit mode, not that it's easy to compare them
> directly. 80-bit long double is fully supported in C, 128-bit quad
> fully supported in Fortran. Evidently, all this support for extended
> precisions has not made a fully successful market for these CPUs.[/color]

It seems that IBM S/370 is the only one with good support for
128 bit, though even they didn't do divide in hardware until
half way through ESA/390, about 10 years ago. But the format was
designed to make software emulation relatively easy, either for all
instructions (S/360 other than the 360/85) or divide.

Only a few VAX models seem to have hardware support for H float,
the 11/730 was the first one I knew about.

-- glen

James Giles wrote:[color=blue]
> Gary Scott wrote:[color=green]
>> James Giles wrote:[/color]
> ...[color=green][color=darkred]
>>> C's expressiveness and flexibility are dubious qualities at best.[/color][/color]
> ...[color=green]
>> I was being facetious. Everytime I've queried the hacker types at
>> work, they always want to discuss pointers ("FORTRAN doesn't even have
>> pointers!", laughs). I tended to discount them from then on.[/color]
>
> I figured that you were being facetious. But, the sad case is that
> many people would recognize it.
>[/color]
Or not ...

On Jul 4, 9:45 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
[color=blue]
> 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.

Steve

On Wed, 4 Jul 2007, Peter Nilsson wrote:[color=blue]
>
> Yes and no. Fact is, aliasing limitations of C90 mean that
> Fortran has the potential for greater optimisations.[/color]

I think you mean C89 (the original ANSI standard C). C99 includes the
"restrict" keyword which is a promise from the programmer to the compiler
that pointers do not point to overlapping memory regions, e.g.

void copy(double * restrict a, double * restrict b, int n)
{
int i;

for (i=0; i<n; i++)
a[i] = b[i];
}

without the "restrict" keyword, the compiler could not auto-parallelize
the loop due to the possibility that the two arrays of doubles could
overlap. With it, the loop iterations can be performed in any order, even
simultaneously.

Chip

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"

Vista wrote:[color=blue]
> Hi all,
>
> Please, allow me to ask this naive question...
>
> I am mainly a programmer in Matlab. Often times for the sake of speed, I
> convert my Matlab program into C/C++, often with the aid of numerical
> libraries such as GSL, IMSL, MKL, etc.
>
> Now I am facing a numerical computation task which need quadruple precison.[/color]

Hello,

I am immediately suspicious of an algorithm that "requires" quadruple precision. That's
not to say that quadruple (or higher) precision isn't required in some cases, but in my
(albeit limited) experience, it's usually an indication of an unsophisticated approach to
a numerical problem.
[color=blue]
> Please see below for a detailed description.
>
> I guess Intel Visual Fortran or other Fortran has natural support for the
> quadruple precision.
>
> I probably will have to pick up my Fortran book and do some Fortran
> programming. (I've touched a little bit of it some years ago).
>
> Now, speed if critical for my application. If somebody tells me that
> Fortran's support of Quadruple precision is about 10% faster than any other
> quadruple solution in any other libraries in C/C++, then I am going to turn
> to Fortran.[/color]

If speed is critical -- though I assume getting the correct answer is the prime
requirement? ) -- then spend some time on developing your algorithm so it doesn't need
quad precision. Then you don't have to worry about red herrings such as "is <language X>
faster than <language Y>?"

More info on the problem you're trying to solve, and how you've approached it so far,
would help.

cheers,

paulv

--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx

Chip Coldwell wrote:
[color=blue]
> On Wed, 4 Jul 2007, Peter Nilsson wrote:[/color]
[color=blue][color=green]
>>Yes and no. Fact is, aliasing limitations of C90 mean that
>>Fortran has the potential for greater optimisations.[/color][/color]
[color=blue]
> I think you mean C89 (the original ANSI standard C).[/color]

He said C90, not C99. It seems that the ANSI standard was
in 1989, and the ISO standard in 1990. Some call it C89,
and some C90.

[url]http://en.wikipedia.org/wiki/ANSI_C[/url]

-- glen

Gib Bogle wrote:[color=blue]
> James Giles wrote:[/color]
....[color=blue][color=green]
>> I figured that you were being facetious. But, the sad case is that
>> many people would recognize it.
>>[/color]
> Or not ...[/color]

It's a strange thing that on my notebook's keyboard I seem to omit
keystrokes while typing - whole sequences of them. Indeed, I touch
the keys, but not hard enough to work. The effect is most noticable
with the omission of things like n't from the end of words. Or 's
when possessive is intended. I do know why (Oh, I mean don't).

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

On 4 Jul, 03:05, "Vista" <a...@gmai.com> wrote:
....
....(re. 128-bit reals in Fortran and C)
....
[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]

Having seen the replies I doubt you will get the 'consensus' you asked
for. Your requirement is quite specific and really, I would say,
demands support from the language implementation for the data types
that interest you.

Given that consensus is not available you could try the language
shootout (Google for it) for broadly similar routines to the ones you
need. That shows comparitive timings.

Failing that, if you have access to the compilers you could go to the
bother of writing one routine in both languages. Once compared you
will have some idea of what to use. (It would be cool if you reported
back.)

Failing all that you could take the third and simplest option, write
in C.

--
HTH,
James

cc. comp.lang.misc. Folks there may have some thoughts on this.
Language performance comparisons are always a good source of debate!