Home > Archive > Fortran > February 2005 > INTENT(WORKSPACE) as a new Fortran feature?
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 |
INTENT(WORKSPACE) as a new Fortran feature?
|
|
| Thomas Koenig 2005-02-16, 9:01 pm |
| What about INTENT(WORKSPACE) as a feature for the next Fortran
standard? This would mark a variable (presumably an array, in most
cases) which doesn't have any predefined values, like INTENT(OUT),
and whose values don't need to be passed to the calling subroutine.
| |
| Richard E Maine 2005-02-16, 9:01 pm |
| In article <cv0agl$5e4$1@meiner.onlinehome.de>,
Thomas Koenig <Thomas.Koenig@online.de> wrote:
> What about INTENT(WORKSPACE) as a feature for the next Fortran
> standard? This would mark a variable (presumably an array, in most
> cases) which doesn't have any predefined values, like INTENT(OUT),
> and whose values don't need to be passed to the calling subroutine.
That's been proposed... almost exactly like that. Dan's proposed
spelling was intent(scratch), but that kind of spelling detail is far
below the level of current debate.
I don't recall the status of the proposal. Might have had inadequate
support to move forward, but I do recall that as one of the things
proposed (and I even recall that Dan Nagle was the proposer).
It wasn't very high on my personal list, but that's beside the point.
--
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
| |
| Dick Hendrickson 2005-02-16, 9:01 pm |
|
Richard E Maine wrote:
> In article <cv0agl$5e4$1@meiner.onlinehome.de>,
> Thomas Koenig <Thomas.Koenig@online.de> wrote:
>
>
>
>
> That's been proposed... almost exactly like that. Dan's proposed
> spelling was intent(scratch), but that kind of spelling detail is far
> below the level of current debate.
>
> I don't recall the status of the proposal. Might have had inadequate
> support to move forward, but I do recall that as one of the things
> proposed (and I even recall that Dan Nagle was the proposer).
>
> It wasn't very high on my personal list, but that's beside the point.
>
At the last meeting, it came out about in the middle of the
B list of things to propose to WG5 for inclusion into
F2003+.
The B list is, roughly speaking, a set of things J3 would
like to work on if there is time. WG5 meets in may to
decide on a first cut of requirements for F2003+.
Dick Hendrickson
| |
| Jan Vorbrüggen 2005-02-17, 9:02 am |
| > What about INTENT(WORKSPACE) as a feature for the next Fortran
> standard? This would mark a variable (presumably an array, in most
> cases) which doesn't have any predefined values, like INTENT(OUT),
> and whose values don't need to be passed to the calling subroutine.
I think a compiler's flow and liveness analysis should nowadays be pretty
good at determining this information. Some even manage to do so when you
re-use such variables' names - yes, many algorithms (being heuristics that
stop at some point in their analysis) can be helped along by using such a
name only in one basic block.
Jan
| |
| Dan Nagle 2005-02-17, 9:02 am |
| Hello,
The difficulty is when there's separate compilation,
as with f77-style procedures, or the new submodules.
Then, interprocedural optimization is problematic.
--=20
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
On Thu, 17 Feb 2005 10:10:22 +0100, Jan Vorbr=FCggen
<jvorbrueggen-not@mediasec.de> wrote:
>
>I think a compiler's flow and liveness analysis should nowadays be =
pretty
>good at determining this information. Some even manage to do so when you
>re-use such variables' names - yes, many algorithms (being heuristics =
that
>stop at some point in their analysis) can be helped along by using such =
a
>name only in one basic block.
>
> Jan
| |
| Jan Vorbrüggen 2005-02-17, 9:02 am |
| > The difficulty is when there's separate compilation,
> as with f77-style procedures, or the new submodules.
> Then, interprocedural optimization is problematic.
AIUI, this feature would improve intraprocedural optimization,
because it was likened to INTENT(OUT) without being an OUT
argument - i.e., it is really a local variable/array. Or is
the intent 8-) to mark some of the BLAS/LAPACK dummy arguments
in this way? Then I'd be against it, because it's a solution
in search of a problem - it would be much better to improve
or modernize the BLAS interfaces than to introduce such a specific
microoptimization into the language.
JAn
| |
| Dan Nagle 2005-02-18, 8:57 am |
| Hello,
On Thu, 17 Feb 2005 12:04:28 +0100, Jan Vorbr=FCggen
<jvorbrueggen-not@mediasec.de> wrote:
<snip>
>AIUI, this feature would improve intraprocedural optimization,
>because it was likened to INTENT(OUT) without being an OUT
>argument - i.e., it is really a local variable/array. Or is
>the intent 8-) to mark some of the BLAS/LAPACK dummy arguments
>in this way? Then I'd be against it, because it's a solution
>in search of a problem - it would be much better to improve
>or modernize the BLAS interfaces than to introduce such a specific
>microoptimization into the language.
Within the called procedure, the intent( scratch) variable
may be aggressively optimized. Without intent( scratch), it can't,
unless the compiler can see that it's not used outside the caller.
>
> JAn
--=20
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Edgar 2005-02-18, 3:59 pm |
| Dan Nagle wrote:
> Within the called procedure, the intent( scratch) variable
> may be aggressively optimized. Without intent( scratch), it can't,
> unless the compiler can see that it's not used outside the caller.
But why not just have the routine allocate its own workspace?
Richard
| |
| Gareth Owen 2005-02-18, 3:59 pm |
| Richard Edgar <rge21@astro.su.se> writes:
> Dan Nagle wrote:
>
>
> But why not just have the routine allocate its own workspace?
Good programmers can write Fortran 77 in any language.
--
Gareth Owen
Usenet is like Tetris for people who still remember how to read
| |
| beliavsky@aol.com 2005-02-18, 3:59 pm |
|
Richard Edgar wrote:
> Dan Nagle wrote:
>
>
> But why not just have the routine allocate its own workspace?
If the subroutine is called many times, it may be faster to allocate
the array once in the caller than each time within the subroutine.
| |
| Jan Vorbrüggen 2005-02-18, 3:59 pm |
| > If the subroutine is called many times, it may be faster to allocate
> the array once in the caller than each time within the subroutine.
No, this doesn't make sense. If the array is small, it will be allocated
on the stack, and this costs exactly 0 instructions in addition (because
the stack pointer is being changed to allocate local variables in any
case); if it's larger, any allocation from the heap will be dwarfed by
the time required to access its contents - unless you're allocating but
not using a large array, in which case not the language but your code is
in urgent need of modification.
My summary: don't pollute the language for such infinitesimal gain.
Jan
| |
| Ron Shepard 2005-02-18, 3:59 pm |
| In article <37mf48F5e539eU1@individual.net>,
Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
>
> No, this doesn't make sense. If the array is small, it will be allocated
> on the stack, and this costs exactly 0 instructions in addition (because
> the stack pointer is being changed to allocate local variables in any
> case); if it's larger, any allocation from the heap will be dwarfed by
> the time required to access its contents - unless you're allocating but
> not using a large array, in which case not the language but your code is
> in urgent need of modification.
I don't think the cost of stack or heap allocation can be known
ahead of time. If garbage collection is required in order to
allocate the space repeatedly, then the time required could be
significant and the associated effort could be nonuniform between
calls. In any case, it is certainly not 0 instructions, especially
for heap allocation. Also, in the small array case, it might result
in the entire array being stored in registers or cache and the
"actual" memory would never be touched at all.
If, on a particular machine, the compiler knows that it would be
faster to allocate local memory rather than the alternatives (copy
in, and/or copy out, or address the memory of the actual argument),
then the compiler could do so as an optimization that it could not
have done before. NUMA memory structures result in some odd memory
optimizations these days, and INTENT(WORKSPACE) gives the compiler
more flexibility and seems to fit into this situation fairly well.
> My summary: don't pollute the language for such infinitesimal gain.
You may be correct here. That's why it is worth discussing. Are
multilevel caches a current fad in computer design, or are they with
us for the foreseeable future? Should the language be adapted to
accommodate them and other NUMA features (such as local and remote
memory address spaces in parallel machines), or should they be
hidden from the high-level language programmer?
$.02 -Ron Shepard
|
|
|
|
|