Home > Archive > Fortran > November 2005 > Pointers versus Allocatables
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Pointers versus Allocatables
|
|
| Joe Krahn 2005-11-21, 9:57 pm |
| I'm sure Pointer versus Allocatable has been discussed a lot. The main
difference is that pointers can point to memory allocated elsewhere, and
allocatables only get to point at their own allocated data.
It seems that they both hold similar array descriptors. But, if that is
true, why do I hear that pointers are often slower? Is it perhaps
because small allocatable arrays can use the stack? Or, maybe it is an
implementation-specific issue, where some compilers use pointers in a
way that there is an additional indirection?
Joe Krahn
| |
| glen herrmannsfeldt 2005-11-22, 4:00 am |
| Joe Krahn wrote:
> I'm sure Pointer versus Allocatable has been discussed a lot. The main
> difference is that pointers can point to memory allocated elsewhere, and
> allocatables only get to point at their own allocated data.
> It seems that they both hold similar array descriptors. But, if that is
> true, why do I hear that pointers are often slower? Is it perhaps
> because small allocatable arrays can use the stack? Or, maybe it is an
> implementation-specific issue, where some compilers use pointers in a
> way that there is an additional indirection?
While you would have to look at a specific implementation to see how
it was actually done, I do agree that the execution time should be
similar. One possibility is that some optimizations might not be
possible for pointers due to possible aliasing.
-- glen
| |
| Richard Maine 2005-11-22, 4:00 am |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> One possibility is that some optimizations might not be
> possible for pointers due to possible aliasing.
More that just a possibility, that is *THE* issue. Whether it is a big
issue or a negligible one will depend on application specifics.... and
also on how "smart" the compiler is about being able to deduce when
aliasing can be ruled out.
Looking at implementation innards isn't going to tell you much. Instead,
you have to look at the algorithms used and whether they would be hurt
by aliasing or not.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2005-11-22, 4:00 am |
| Richard Maine wrote:
(snip)
> More that just a possibility, that is *THE* issue. Whether it is a big
> issue or a negligible one will depend on application specifics.... and
> also on how "smart" the compiler is about being able to deduce when
> aliasing can be ruled out.
I suppose I haven't been convinced that aliasing is that much
of a problem. Not that it can't make a difference, but there are a
number of things that can effect execution time, caching and branch
(mis)prediction being two that I can think of. Processors are getting
better at branch prediction, and some people do write algorithms to
optimize the cache usage, after which it might be worth looking at
aliasing.
> Looking at implementation innards isn't going to tell you much. Instead,
> you have to look at the algorithms used and whether they would be hurt
> by aliasing or not.
Well, the algorithm and the implementation and the processor it is
running on.
-- glen
| |
| Jon Harrop 2005-11-22, 7:01 pm |
| glen herrmannsfeldt wrote:
> I suppose I haven't been convinced that aliasing is that much
> of a problem. Not that it can't make a difference, but there are a
> number of things that can effect execution time, caching and branch
> (mis)prediction being two that I can think of. Processors are getting
> better at branch prediction, and some people do write algorithms to
> optimize the cache usage, after which it might be worth looking at
> aliasing.
I have seen pointer aliasing make huge performance differences. Albeit only
in C vs Fortran benchmarks written by Fortran advocates. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
| |
| Greg Lindahl 2005-11-22, 7:01 pm |
| In article <43838da9$0$9473$ed2619ec@ptn-nntp-reader02.plus.net>,
Jon Harrop <usenet@jdh30.plus.com> wrote:
>I have seen pointer aliasing make huge performance differences. Albeit only
>in C vs Fortran benchmarks written by Fortran advocates. ;-)
A bunch of the C SPECfp benchmarks have interesting pointer aliasing
issues that must be solved to get good performance.
-- greg
| |
|
|
"Joe Krahn" <jkrahn@nc.rr.com> wrote in message
news:oAwgf.2698$q93.1007428@twister.southeast.rr.com...
> I'm sure Pointer versus Allocatable has been discussed a lot. The main
> difference is that pointers can point to memory allocated elsewhere, and
> allocatables only get to point at their own allocated data.
Elements of an allocatable array can be accessed using an index. Do Fortran
pointers allow access by an index? Are you camparing the access speed of an
array with index to navigating a linked list?
>
> It seems that they both hold similar array descriptors. But, if that is
> true, why do I hear that pointers are often slower? Is it perhaps because
> small allocatable arrays can use the stack? Or, maybe it is an
> implementation-specific issue, where some compilers use pointers in a way
> that there is an additional indirection?
>
> Joe Krahn
| |
| Richard E Maine 2005-11-22, 7:01 pm |
| apm <Contributor@AdsorptionProcessModeling.com> wrote:
> Elements of an allocatable array can be accessed using an index. Do Fortran
> pointers allow access by an index?
Yes. This is essentially unrelated. Pointers can be to arrays. So can
allocatables. So can things that are neither. Arrayness has little to
do with being a pointer or allocatable or not.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Michael Metcalf 2005-11-22, 7:01 pm |
|
"apm" <Contributor@AdsorptionProcessModeling.com> wrote in message
news:2gNgf.42087$4n5.6361@dukeread01...
>
>
> Elements of an allocatable array can be accessed using an index. Do
> Fortran pointers allow access by an index? Are you camparing the access
> speed of an array with index to navigating a linked list?
>
Unlike Richard, I interpret this question as meaning 'can you have an array
of pointers'? To which the answer is no.
Regards,
Mike Metcalf
| |
| Greg Lindahl 2005-11-22, 7:01 pm |
| In article <2gNgf.42087$4n5.6361@dukeread01>,
apm <Contributor@AdsorptionProcessModeling.com> wrote:
>Elements of an allocatable array can be accessed using an index. Do Fortran
>pointers allow access by an index? Are you camparing the access speed of an
>array with index to navigating a linked list?
Unlike Richard and Mike, I think this is confusing how pointers and
allocatable arrays work. A pointer to an array is indexed like an
array. An allocatable array is indexed like an array. You can
construct linked lists if you want, but you won't get one by surprise
if you are using a pointer to an array. Perhaps the poster is
confusing Fortran pointers to C pointers, where you can end up with an
array of pointers to arrays of pointers to 1D vectors. Fortunately you
can't do that in Fortran. And it does hurt in C.
-- greg
| |
| Joe Krahn 2005-11-23, 3:57 am |
| Michael Metcalf wrote:
> "apm" <Contributor@AdsorptionProcessModeling.com> wrote in message
> news:2gNgf.42087$4n5.6361@dukeread01...
>
>
>
> Unlike Richard, I interpret this question as meaning 'can you have an array
> of pointers'? To which the answer is no.
>
> Regards,
>
> Mike Metcalf
>
You can have an array of pointers by wrpping the pointers in a derived
type. This is sort of what you get with an array of
type(varying_string), except that it uses allocatables instead.
Joe
| |
| glen herrmannsfeldt 2005-11-25, 7:00 pm |
| Greg Lindahl wrote:
(snip)
> Perhaps the poster is
> confusing Fortran pointers to C pointers, where you can end up with an
> array of pointers to arrays of pointers to 1D vectors. Fortunately you
> can't do that in Fortran. And it does hurt in C.
It is unfortunate that C only allows that method for dynamically sized
multidiminsional arrays. Though in cases where the pointed to arrays
are not all the same size it does have an advantage over rectangular arrays.
Fortran does allow arrays structures containing pointers. (At least
some versions of the standard use the word structure to describe the
result of a derived type.) That is probably even less readable than the
C array of pointers to vectors.
Note that if only the leftmost (in C) subscript is dynamically sized one
can generate something more similar to a Fortran array in C. This is
rarely done, though, partly because it is even more confusing than the
array of pointers, and also because of the difficulty passing it as an
argument to another function.
Something like:
double (*x)[10][10];
declares x as a pointer, to one or more 10 by 10 arrays,
where x can be dynamically allocated and will point to contiguously
allocated memory. When allocated that way, it cannot be passed to a
called function expecting an array of pointers.
-- glen
|
|
|
|
|