Re: Is Fortran still faster than C for math applications?

On Thu, 5 Jan 2006 23:31:39 +0200 (EET), Janne Blomqvist
<foo@xxxxxxxxxxx> wrote:

> glen herrmannsfeldt wrote:
> > In many cases it might be true. C tends to be a lower level language,
> > which in many cases will result in smaller, faster code.
>
> I'm not so sure about that. Surely a Fortran binary will be slightly
> larger than the corresponding C program, since it needs to link in the
> runtime library (in addition to libc), init it and start the main

There's no inherent reason a Fortran library/runtime must use the (or
a) C library, although it seems to have become a somewhat popular
implementation technique. Looking merely at required functionality
Fortran requires a little more in I/O, substantially more in math
before C99 which has nearly closed the gap, and about the same
(little) in other areas, and IME total library sizes of (IMJ)
'reasonable' implementations have generally reflected this.

Depending on the platform and implementation (and perhaps options) the
linker may omit parts of the library that aren't needed for a
particular program; IME C libraries have generally been better at this
'tailoring' than Fortran, but my Fortran use has not been on the small
or constrained machines where this is important and thus there was not
much if any need or incentive for the implementor to do it.

For that matter, depending on platform and implementation and options,
the C library, the Fortran library, both, or neither, or part(s) of
either or both or neither and/or various other libraries, may be
available without being (counted) in the executable at all.

> program etc. But, unless your computing experience consists of hello
> world or equally trivial programs I have a hard time imagining that
> the above might actually make any significant difference.
>
.... which only strengthens the case that this is a useless metric.

Even if we consider only the code executed for the program (on some
reasonably selected data), whether generated by the compiler or pulled
in by the linker or similar, and ignoring effectively-dead code which
just wastes space which rarely matters much, IME _on the whole_ (and
there are _plenty_ of exceptions) C generates less code per statement
or line but requires more statements/lines for the same nontrivial
functionality, so the total code for a given problem comes out about
the same -- if not actually identical as can happen for an accurately
ported program run through good compilers for each language.

- David.Thompson1 at worldnet.att.net
.

Relevant Pages

  • Re: compiling with cmake and xlf
    ... indicate fixed-form source and add that flag ... My understanding of xlf is that it does the opposite. ... fortran compilers regarding source file names. ... libraries are continually in conflict with various other C and POSIX ...
    (comp.lang.fortran)
  • Re: C vs. Fortran (half OT questions)
    ... I still need the power of C in system programming though. ... An example of this is the ATLAS BLAS ... fortran is probably the more natural language for things ... This was not always the case for numerical libraries, ...
    (comp.lang.fortran)
  • Re: Matlab Vectorisation Speed - How is it done in c++?
    ... Beating the performance of vectorized Matlab code is very ... Matlab makes calls to optimized C and Fortran libraries ... Use optimization level 3 on numerical code and level 2 on non- ...
    (comp.soft-sys.matlab)
  • Re: can somebody verify this C program which calls dsaupd_ ? (longish)
    ... >>>(terribly sorry for this long post which includes my two source files, ... > is NOT relevant to FORTRAN language newsgroup. ... More importantly, if your libraries compiled correctly, they were fine. ... > FORTRAN libs. ...
    (sci.math.num-analysis)
  • Re: GTK+ and Fortran 2003
    ... Install gfortran and the GTK2 development files (headers and static ... Windows: ... Select fortran. ...
    (comp.lang.fortran)