Re: Language efficiency of C versus FORTRAN et al
From: Tim Prince (tprince_at_nospamcomputer.org)
Date: 12/27/04
- Next message: Gregory Toomey: "Re: Language efficiency of C versus FORTRAN et al"
- Previous message: Mac: "Re: scanf in a for loop"
- In reply to: travisperkins03_at_hotmail.com: "Language efficiency of C versus FORTRAN et al"
- Next in thread: Gregory Toomey: "Re: Language efficiency of C versus FORTRAN et al"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Dec 2004 03:12:41 GMT
<travisperkins03@hotmail.com> wrote in message
news:1104112325.276496.291380@f14g2000cwb.googlegroups.com...
> Hi,
>
> I have read somewhere that C code sometimes cannot be compiled to be as
> efficient as FORTRAN, eg for matrix multiplication, because a C
> compiler cannot make the assumptions about arrays that a FORTRAN
> compiler can. But I don't understand the example, not least because I
> don't understand FORTRAN. I also don't understand why it is more
> efficient in this case for a compiler to choose the order of evaluation
> (or whatever it is that it does for matrix multiplication to make it
> faster).
>
> Can anyone explain all this, please? And how much speed-up might one
> get from using FORTRAN over C for such things? What sort of compilers
> offer the best performance for issues like this? Is there any general
> advice about how to achieve efficient code for such linear algebra?
>
> This is a fairly live issue, because matrix mulitplication (and other
> things, like evaluating a dot product) often take an extremely long
> time for large matrices and vectors.
>
Although Fortran (since 15 years ago) provides matmul() and dot_product()
intrinsics, this is only a matter of convenience. As these operations, in
themselves, don't offer any danger of over-writing their operands, the
larger differences in potential efficiency lie elsewhere, provided you don't
choose an algorithm which is more awkward in one language than the other.
Compilers tend to ignore differences in restrictions on order of evaluation;
"vectorizing" compilers are likely to implement them the same way in C and
Fortran. Even on a single CPU, it is generally necessary to break them down
into 8 or so batch sums which can be calculated in parallel. In principle,
the Fortran intrinsics could incorporate MP parallelism, but in practice,
that is likely to depend on application of OpenMP, which is not part of
either language, but works the same way with either.
For large matrix multiplication (say, with minimum dimension 24 or more) or
dot products, you may want to use a library optimized for your processor,
usually following the BLAS schemes. If you are trying to avoid wrapper
overhead in calling basic BLAS, that is written with an old-style Fortran
interface, which requires some study to emulate in C. Other than that,
differences in efficiency among calling languages or compilers disappear,
for those operations supported in the library.
If you do have operations which one compiler succeeds in vectorizing
effectively, while another fails, the speedup could range up to a factor of
6 or so on common processors. It may be more difficult to achieve that in
C, requiring full use of restrict keywords and the like, and maybe more hand
optimization of the code. If you are "restricted" to a C subset, or are
required to use options which support violations of the C standard, you may
have no hope of matching Fortran performance.
- Next message: Gregory Toomey: "Re: Language efficiency of C versus FORTRAN et al"
- Previous message: Mac: "Re: scanf in a for loop"
- In reply to: travisperkins03_at_hotmail.com: "Language efficiency of C versus FORTRAN et al"
- Next in thread: Gregory Toomey: "Re: Language efficiency of C versus FORTRAN et al"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
