OT: Of C, Fortran and pointer aliasing Was: Python if far from a top performer...
|Thus Spake Rainer Deyke On the now historical date of Sun, 11 Jan 2004
06:46:50 +0000|
[color=blue]
> Samuel Walters wrote:[color=green]
>> So, I guess that my point is that C might not be the right language for
>> doing numerical processing, but it seems the right language for
>> implementing the primitives of numerical processing.[/color]
>
> The issue with C is that it is too slow for implementing those
> primitives (in part due to pointer aliasing issues). Fortran is
> considerably faster.[/color]
I stand corrected.
Please help me to understand the situation better.
I went digging for technical documents, but thus far haven't found many
useful ones. It seems everyone but me already understands pointer
aliasing models, so they might discuss them, but they don't explain them.
I am limited in part by my understanding of compilers and also by my
understanding of Fortran. Here is what I have gathered so far:
Fortran lacks a stack for function calls. This promotes speed, but
prevents recursive functions. (Most recursive functions can efficiently be
written as loops, though, so this shouldn't be considered a hindrance.)
Fortran passes all arguments by reference. (This is the peppiest way to do
it, especially with static allocation)
Fortran 77 lacks explicit pointers and favors static allocation. This
allows for the compiler to apply powerful automatic optimization.
Fortran 90 added explicit pointers, but required them to only be pointed
at specific kinds of objects, and only when those particular objects are
declared as targets for pointers. This allows the compiler to still apply
powerful automatic optimizations to code. I'm a bit hazy as to whether
Fortran 90 uses static or dynamic allocation, or a combination of both,
and whether it permits recursion.
These pointers not only reference location, but also dimension and stride.
Stride is implicit in C pointer declarations (by virtue of compile-time
knowledge of the data type pointed to) but dimension is not.
Fortran's extensions for parallel programming have been standardized, and
the language itself makes it easy to decide how to parallelize procedures
at compile time. Thus, it is especially favored for numeric computation on
big iron with lots of parallelism.
Now, for C:
Because of dynamic allocation on the stack and the heap, there is no
compile-time knowledge of where a variable will live, which adds an extra
layer of reference for even static variables. This also invalidates many
of optimizations used by Fortran compilers.
C lacks many of the fundamental array handling semantics and primitives
that Fortran programs rely on. Implementing them in C is a real PITA.
C memory allocation is just plain goofy in comparison to Fortran.
To sum up:
Fortran sacrifices generality and dynamism for compile-time knowledge
about data, and deeply optimizes based on that knowledge.
C sacrifices speed for the sake of generality and dynamism.
Please correct me or help me flesh out my ideas. Please don't skimp on
the low-level details, I've done my fair share of assembly programming, so
what I don't understand, I'll probably be able to find out by googling a
bit.
Some other interesting things I found out:
There are two projects that allow interfacing between Python and Fortran:
F2Py
PyFortran
Fortran amply supports interfaces to C and C++
Fortran is compiled. (Doh! and I thought it was interpreted.)
There are lots of debates on whether C++ will ever be as fast as Fortran.
The consensus seems to be "Only if you use the right compiler with the
right switches and are insanely careful about how you program. IOW Don't
bother, just use Fortran if you want to do numeric processing.
Well, there's another language to add to my list of languages to learn. It
seems to be "The Right Tool" for a great many applications, it interfaces
well with other languages, and it's extremely portable. Chances are, I'll
end up using it somewhere somehow someday. Now. To find some Fortran
tutorials.
Thanks in advance for any of your knowledge and wisdom you are willing to
confer upon me.
Sam Walters.
--
Never forget the halloween documents.
""" Where will Microsoft try to drag you today?
Do you really want to go there?"""
|Thus Spake Rainer Deyke On the now historical date of Sun, 11 Jan 2004
06:46:50 +0000|
[color=blue]
> Samuel Walters wrote:[color=green]
>> So, I guess that my point is that C might not be the right language for
>> doing numerical processing, but it seems the right language for
>> implementing the primitives of numerical processing.[/color]
>
> The issue with C is that it is too slow for implementing those
> primitives (in part due to pointer aliasing issues). Fortran is
> considerably faster.[/color]
I stand corrected.
Please help me to understand the situation better.
I went digging for technical documents, but thus far haven't found many
useful ones. It seems everyone but me already understands pointer
aliasing models, so they might discuss them, but they don't explain them.
I am limited in part by my understanding of compilers and also by my
understanding of Fortran. Here is what I have gathered so far:
Fortran lacks a stack for function calls. This promotes speed, but
prevents recursive functions. (Most recursive functions can efficiently be
written as loops, though, so this shouldn't be considered a hindrance.)
Fortran passes all arguments by reference. (This is the peppiest way to do
it, especially with static allocation)
Fortran 77 lacks explicit pointers and favors static allocation. This
allows for the compiler to apply powerful automatic optimization.
Fortran 90 added explicit pointers, but required them to only be pointed
at specific kinds of objects, and only when those particular objects are
declared as targets for pointers. This allows the compiler to still apply
powerful automatic optimizations to code. I'm a bit hazy as to whether
Fortran 90 uses static or dynamic allocation, or a combination of both,
and whether it permits recursion.
These pointers not only reference location, but also dimension and stride.
Stride is implicit in C pointer declarations (by virtue of compile-time
knowledge of the data type pointed to) but dimension is not.
Fortran's extensions for parallel programming have been standardized, and
the language itself makes it easy to decide how to parallelize procedures
at compile time. Thus, it is especially favored for numeric computation on
big iron with lots of parallelism.
Now, for C:
Because of dynamic allocation on the stack and the heap, there is no
compile-time knowledge of where a variable will live, which adds an extra
layer of reference for even static variables. This also invalidates many
of optimizations used by Fortran compilers.
C lacks many of the fundamental array handling semantics and primitives
that Fortran programs rely on. Implementing them in C is a real PITA.
C memory allocation is just plain goofy in comparison to Fortran.
To sum up:
Fortran sacrifices generality and dynamism for compile-time knowledge
about data, and deeply optimizes based on that knowledge.
C sacrifices speed for the sake of generality and dynamism.
Please correct me or help me flesh out my ideas. Please don't skimp on
the low-level details, I've done my fair share of assembly programming, so
what I don't understand, I'll probably be able to find out by googling a
bit.
Some other interesting things I found out:
There are two projects that allow interfacing between Python and Fortran:
F2Py
PyFortran
Fortran amply supports interfaces to C and C++
Fortran is compiled. (Doh! and I thought it was interpreted.)
There are lots of debates on whether C++ will ever be as fast as Fortran.
The consensus seems to be "Only if you use the right compiler with the
right switches and are insanely careful about how you program. IOW Don't
bother, just use Fortran if you want to do numeric processing.
Well, there's another language to add to my list of languages to learn. It
seems to be "The Right Tool" for a great many applications, it interfaces
well with other languages, and it's extremely portable. Chances are, I'll
end up using it somewhere somehow someday. Now. To find some Fortran
tutorials.
Thanks in advance for any of your knowledge and wisdom you are willing to
confer upon me.
Sam Walters.
--
Never forget the halloween documents.
""" Where will Microsoft try to drag you today?
Do you really want to go there?"""
Comment