KFL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU.UUCP (07/14/86)
From: cetron%utah-cbd@utah-cs.arpa (Ed Cetron)
On the other hand, C does this kind of stuff extremely well - but it
is terrible for large brute force number crunching - and it is ludicrous to
use it in that fashion....
I have heard this several times, and I still don't understand it. I
can see why C is better for systems programming than Fortran or Pascal,
but why is C supposedly worse at number crunching than Fortran? What can
be done easily in Fortran that is difficult or impossible in C?
...Keithcetron%utah-cbd@UTAH-CS.ARPA (Ed Cetron) (07/14/86)
I have found (totally empirically) that trying to code large algorithms is C is somewhat confusing since in order to optimize the calculations one must code it that way. I have yet to see a C compiler that optimizes the numerical calculations (i.e. keeping things in registers to use in chained calculations). Additionally, C in the 'proper' standard is supposed to do everything in double precison and simply convert on input/output (yes i know not all compilers do this....) and for certain operations (such as integer calculations) this is highly ineffecient. C is not so much worse that FORTRAN for simply coding a problem where speed is not critical, but for large algorithms where speed is very important, the FORTRAN compilers tend to give smaller and faster code than do the C compilers.... NOTE WELL: this is a broad generalization and there will always be several specific cases which will prove something (or anything) else... -ed cetron
GROPP-BILL@YALE.ARPA.UUCP (07/15/86)
From: cetron%utah-cbd@utah-cs.arpa (Ed Cetron)
On the other hand, C does this kind of stuff extremely well -
but it is terrible for large brute force number crunching - and
it is ludicrous to use it in that fashion....
I have heard this several times, and I still don't understand it. I
can see why C is better for systems programming than Fortran or Pascal,
but why is C supposedly worse at number crunching than Fortran? What can
be done easily in Fortran that is difficult or impossible in C?
There are two main reasons, one real, the other historical. The first
reason is that c does all floating point operations in double (KR p 184,
section 6.2). This can be a serious problem in applications that
require only float precision. The historical reason comes from the fact
that most professionally done Fortran compilers for the faster, number
crunching machines generate significantly better object code than c
compilers on the same machine. This can be traced to the early
development of c (the "register" declaration is of no use/need to
sufficiently sophisticated code generator; note section 8.1 in KR) and
the continuing belief by many that c generates excellent code. This
belief, where true at all, generally does not apply to floating point
operations and the kinds of expressions that contain them.
Also, it is impossible to pass a 2 or higher dimensioned array AS SUCH
where the dimensions are not known at compile time (section 8.3 and 15,
KR). Instead, you must pass a pointer and do the pointer arithmetic
yourself. This can be extremely inconvenient in many number-crunching
applications. For an example, consider a subroutine library to handle
matrices of arbitrary size such as the Fortran LINPACK and EISPACK.
Finally, there is the portability question. Many number-crunching
programs are intended for wide distribution on the large mainframes,
many of which did not (some still do not) have a c compiler.
Having said all of that, there are clearly cases, particularly in
fancier numerical codes using adaptivity and needed dynamic memory
allocation and structures, where c is often the best choice.
Bill
-------CUNNINGHAMR%HAW.SDSCNET@LLL-MFE.ARPA.UUCP (07/15/86)
Number crunching in FORTRAN vs. C. In geophysical---and many other---applications, `number crunching' means dealing with multi-dimensional arrays of complex (not real) numbers. Commonly-used routines (e.g., FFTs and similar transforms) effectively have to be coded so that array bounds are not hard-wired at compile time. The FORTRAN syntax involved tends to be fairly straightforward, reasonably mirroring the algorithms involved. C code for such things gets very complicated early on and it's easy to lose the feel of what the algorithms are really doing. My personal opinion is that too many details have to be buried too deeply in such code.