Home > Archive > Fortran > February 2007 > C_F_POINTER, aliasing and performance
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 |
C_F_POINTER, aliasing and performance
|
|
| Sebastian Hanigk 2007-02-08, 4:12 am |
| Hello!
I'm currently experimenting with the ISO_C_BINDING module, especially
the C_F_POINTER subroutine, to couple a C library with my Fortran code.
Suppose I have two Fortran pointer variables f_ptr_a and f_ptr_b which
will be associated with C-allocated memory by the C_F_POINTER routine in
such a way that the two C pointers used do not hold disjunct memory
patches:
REAL, DIMENSION (m,n), POINTER :: f_ptr_a
REAL, DIMENSION (j,k), POINTER :: f_ptr_b
TYPE (C_PTR) :: c_ptr_a, c_ptr_b
! c_ptr_a and c_ptr_b get their values assigned by an external routine
! and do alias or overlap
CALL C_F_POINTER (c_ptr_a, f_ptr_a, (/ m, n /))
CALL C_F_POINTER (c_ptr_b, f_ptr_b, (/ j, k /))
As far as I know, aliasing would be erroneous if I had used Cray
pointers in a similar manner, but how is it with the F2003 interop
facilities? Furthermore, how's performance?
Regards,
Sebastian
| |
| Walter Spector 2007-02-08, 7:07 pm |
| Sebastian Hanigk wrote:
> As far as I know, aliasing would be erroneous if I had used Cray
> pointers in a similar manner, but how is it with the F2003 interop
> facilities? Furthermore, how's performance?
Correct on both points. With F90 pointers, you can legally create
aliasing situations. So compilers must assume this and may generate
more conservative code than might otherwise be the case.
W.
| |
| Sebastian Hanigk 2007-02-08, 7:07 pm |
| Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
>
> Correct on both points. With F90 pointers, you can legally create
> aliasing situations. So compilers must assume this and may generate
> more conservative code than might otherwise be the case.
Okay. In my case I do know that no aliasing will occur, is there a
possibility to tell this to the compiler? With the gcc one could give the
"-fno-alias" option and the PGI compiler understands "-Mcray=pointer",
but this all very compiler dependent.
Bye,
Sebastian
| |
| Steve Lionel 2007-02-08, 7:07 pm |
| On Feb 8, 10:01 am, Sebastian Hanigk <han...@in.tum.de> wrote:
> Okay. In my case I do know that no aliasing will occur, is there a
> possibility to tell this to the compiler? With the gcc one could give the
> "-fno-alias" option and the PGI compiler understands "-Mcray=pointer",
> but this all very compiler dependent.
There is no standard-conforming way to do this. You'll have to check
the documentation for your particular compiler.
However, Fortran does have rules about aliasing and what you can and
cannot do if there is overlap.
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
My Fortran blog
http://www.intel.com/software/drfortran
| |
| Walter Spector 2007-02-08, 7:07 pm |
| Sebastian Hanigk wrote:
> ... In my case I do know that no aliasing will occur, is there a
> possibility to tell this to the compiler?
Pass the data to a subroutine, and "forget" to tell the subroutine
that the data is a TARGET. Do all your computations in the subroutine.
W.
| |
| Walter Spector 2007-02-08, 7:07 pm |
| Richard Maine wrote:
> ...
> So-called Cray pointers are not "Fortran pointers", so that's a
> different subject. It is certainly possible to make Cray pointers
> overlap also, but since there is no standard for Cray pointers, I cannot
> say whether that is "allowed" or just something that is possible to do
> but not "allowed".
Well, the Cray implementation of Cray pointers assumed no overlap.
In fact, there were warnings not to do overlaps in the Cray ref manuals.
(Didn't stop folks from trying, though. As in many things, sometimes
one could get away with it, and other times not.)
W.
| |
| Sebastian Hanigk 2007-02-08, 7:07 pm |
| nospam@see.signature (Richard Maine) writes:
> Note that none of this has anything in particular to do with the C
> interop stuff. It is a property of Fortran pointers that they may
> overlap. It doesn't much have anything to do with how they got
> defined.
I assume that the more restrictive nature of Fortran pointers (in
contrast to C pointers) makes it possible to deal with (potential)
aliasing in a more efficient way.
Regarding my original question, it seems that possible aliasing of the C
pointers and therefore their associated Fortran pointers is OK because
the Fortran pointer facilities allow for aliased pointers.
> So-called Cray pointers are not "Fortran pointers", so that's a
> different subject. It is certainly possible to make Cray pointers
> overlap also, but since there is no standard for Cray pointers, I cannot
> say whether that is "allowed" or just something that is possible to do
> but not "allowed".
As far as I had understood the documentation on Cray pointers, it is
more or less forbidden to alias memory blocks - or if aliasing occurs,
the program's results are undefined.
Sebastian
| |
| Sebastian Hanigk 2007-02-08, 7:07 pm |
| Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
>
> Pass the data to a subroutine, and "forget" to tell the subroutine
> that the data is a TARGET. Do all your computations in the subroutine.
Won't I suffer from copy-in/copy-out? The nice thing in my case is that
the memory allocated via C routines will be registered with the
high-performance communication interface to faciliate zero-copy
transfers. Working on a memory copy of the original will lead to
performance degradation due to buffering and copying of the transferred
data. Or is the copy-in/copy-out mechanisms only employed if the passed
array is non-contiguous in memory?
Sebastian
| |
| glen herrmannsfeldt 2007-02-08, 7:07 pm |
| Sebastian Hanigk wrote:
(snip)
> Won't I suffer from copy-in/copy-out? The nice thing in my case is that
> the memory allocated via C routines will be registered with the
> high-performance communication interface to faciliate zero-copy
> transfers. Working on a memory copy of the original will lead to
> performance degradation due to buffering and copying of the transferred
> data. Or is the copy-in/copy-out mechanisms only employed if the passed
> array is non-contiguous in memory?
If the calling routine can't be sure it is contiguous, and the called
routine has an assumed size dummy then it might make a copy.
An assumed shape dummy allows discontiguous arrays, and shouldn't
need a copy. Some will check for actual non-contiguous arrays
before making the copy, others won't.
-- glen
| |
| Tim Prince 2007-02-08, 10:05 pm |
| Walter Spector wrote:
> Richard Maine wrote:
>
> Well, the Cray implementation of Cray pointers assumed no overlap.
> In fact, there were warnings not to do overlaps in the Cray ref manuals.
> (Didn't stop folks from trying, though. As in many things, sometimes
> one could get away with it, and other times not.)
>
ifort assumes aliasing in Cray pointers, by default. If you want
optimizations
around Cray pointers, you need the -safe_cray_ptr option. While I have
never seen Cray pointers used with aliasing, the compiler had to take
the possibility into account.
I'm somewhat amused at the idea that someone could call it a Cray
pointer, if it doesn't follow the Cray rules.
| |
| Richard Maine 2007-02-09, 4:10 am |
| Tim Prince <tprince@nospamcomputer.org> wrote:
> I'm somewhat amused at the idea that someone could call it a Cray
> pointer, if it doesn't follow the Cray rules.
I'm far from an expert at Cray pointers. I've had to deal with them on
occasion in 3rd party codes, but I never used them myself because 1)
they seemed counter-intuitive and hard to understand to me, and 2) they
weren't supported in all teh compilers that I needed portability to
anyway.
But... I've seen enough of them to know that there are substantial
differences in detail among implementations, all still going by the name
of "Cray pointers". Start with the differences arising from 32-bit vs
64-bit addressing (not to speak of 60). This does show up in ways that
require source code changes in porting. Then there are the
implementations that allow "Cray pointers" to procedures.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Jugoslav Dujic 2007-02-09, 4:10 am |
| Sebastian Hanigk wrote:
| Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
|
||| ... In my case I do know that no aliasing will occur, is there a
||| possibility to tell this to the compiler?
||
|| Pass the data to a subroutine, and "forget" to tell the subroutine
|| that the data is a TARGET. Do all your computations in the subroutine.
|
| Won't I suffer from copy-in/copy-out? The nice thing in my case is that
| the memory allocated via C routines will be registered with the
| high-performance communication interface to faciliate zero-copy
| transfers. Working on a memory copy of the original will lead to
| performance degradation due to buffering and copying of the transferred
| data. Or is the copy-in/copy-out mechanisms only employed if the passed
| array is non-contiguous in memory?
Note that copy-in/copy-out, in practice, can occur only with assumed-size
dummies (while compiler, in theory, might be smart enough to employ it
with assumed-shape if it's more efficient, I doubt any does it, so let's
put that aside).
As for your other question (whether copy-in/copy-out can occur on contiguous
arrays), quality of implementation varies. Being familiar only with the VF
family, I can tell that CVF was fairly bad at it, doing copy in/out
more or less whenever it saw a colon (or pointer attribute) in the actual
argument, but its successor IVF now employs run-time contiguity tests.
But, as I said, the issue is moot if you use assumed-shape dummies.
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
| James Giles 2007-02-09, 4:10 am |
| Jugoslav Dujic wrote:
....
> Note that copy-in/copy-out, in practice, can occur only with
> assumed-size dummies (while compiler, in theory, might be
> smart enough to employ it with assumed-shape if it's more
> efficient, I doubt any does it, so let's put that aside).
Superficially I would have assumed the declaration of the
dummy to be irrelevant to whether a copy is made. Passing
contiguous actual arguments by reference seems the obvious
thing to do whether the dummy is assumed (-size, or -shape)
or explicit shape. Passing discontiguous slices by copy-in/-out
is pretty much required for assumed-size and explicit-shape
dummies. Doing the same for assumed-shape would simplify
the compiler's job by making all parameter passing the same.
To be sure, for the purposes of speed compilers need to be
smart (smarter than some are) to recognize when a slice is
or is not contiguous. But copying, when actual argument
*is* discontiguous, is not necessarily less efficient. It improves
cache coherency of references within the procedure. People
are often fooled by benchmarks that strip out the content
of the procedure and only measure parameter passing. Of
course, some explicit way for the programmer him(her)self
to control whether copies are made would help. Right now
the only explicit control is one-way: you *can* make an
explicit copy before calling. You can't explicitly tell the
compiler not to copy.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Gary Scott 2007-02-09, 8:07 am |
| Tim Prince wrote:
> Walter Spector wrote:
>
> ifort assumes aliasing in Cray pointers, by default. If you want
> optimizations
> around Cray pointers, you need the -safe_cray_ptr option. While I have
> never seen Cray pointers used with aliasing, the compiler had to take
> the possibility into account.
> I'm somewhat amused at the idea that someone could call it a Cray
> pointer, if it doesn't follow the Cray rules.
I thought IVF (or CVF) called them "integer" pointers.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2007-02-09, 7:07 pm |
| Jugoslav Dujic <jdujic@yahoo.com> wrote:
> Note that copy-in/copy-out, in practice, can occur only with assumed-size
> dummies
and explicit shape. That is a very important case, as much f77 code uses
it. In fact, all f77 code uses either explicit shape or assumed size,
those being the only two options then. That's even one way to remember
the rule; it is no coincidence.
> (while compiler, in theory, might be smart enough to employ it
> with assumed-shape if it's more efficient, I doubt any does it, so let's
> put that aside).
Yes, there exist compilers that can do copy for assumed shape. The NAG
compiler has done so for ages, for example. However, it tends to be
controlled by a user-specified switch, rather than having the compiler
try to figure out when it might be beneficial.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
|
|
|
|