Home > Archive > Fortran > July 2006 > What is the benefit of USE, ONLY(!)
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 |
What is the benefit of USE, ONLY(!)
|
|
| Matthias Möller 2006-07-18, 4:00 am |
| Hi,
I was asked by a colleague what is the great benefit of the ONLY
qualifier in combination with the USE statement. Well, I think together
with 'renaming' it enables you to do something like
USE crs7_operations, ONLY : matmul7 => matrix_vector_multiplication
USE crs9_operations, ONLY : matmul9 => matrix_vector_multiplication
That is, both modules provide exactly the same methods but differ, e.g.,
in the way of implementation (performance, safety) and/or data types. If
you omit the ONLY statement then you will have to rename ALL methods by
hand. Is this right?
Can you image other situations in which the ONLY qualifier brings
additional advantages.
I need some 'advantages' because my colleague reported that the time for
compiling (ifc,g95) the code drastically increases when USE ... ONLY is
employed.
Thanks in advance,
Matthias Moeller
| |
| Jan Vorbrüggen 2006-07-18, 4:00 am |
| > Can you image other situations in which the ONLY qualifier brings
> additional advantages.
It makes clear what parts of a module are actually used (or intended to be
used) and avoids cluttering the name space - i.e., symbols coming into scope
that you don't want to have or even don't know of.
> I need some 'advantages' because my colleague reported that the time for
> compiling (ifc,g95) the code drastically increases when USE ... ONLY is
> employed.
I see no reason - except a decidedly sub-optimal implementation - why that
should be the case. Are the versions of the compilers you are using the
current ones?
Jan
| |
| Matthias Möller 2006-07-18, 4:00 am |
| Jan Vorbrüggen schrieb:
>
> It makes clear what parts of a module are actually used (or intended to be
> used) and avoids cluttering the name space - i.e., symbols coming into
> scope
> that you don't want to have or even don't know of.
>
>
> I see no reason - except a decidedly sub-optimal implementation - why that
> should be the case. Are the versions of the compilers you are using the
> current ones?
This is what my colleague measured
ifort 9.1.038 (32bit):
0' 1'' nur mit use
1'20'' mit use only
ifort 9.1.038 (64bit):
0' 1'' nur mit use
1'13'' mit use only
g95 2006-07-11:
0' 0.3'' nur mit use
0' 6'' mit use only
Matthias
| |
| Bil Kleb 2006-07-18, 7:59 am |
| Matthias Möller wrote:
> Hi,
Hello.
> Can you image other situations in which the ONLY qualifier brings
> additional advantages.
We use it for evolving our software design by looking at the
only patterns. For example, you may find that only a small
subset of a given module actually gets used repeatedly, and
gives one a candidate for splitting the module or moving
the particular method to another module.
ONLYs are part of our coding standard -- see website below.
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
| |
| beliavsky@aol.com 2006-07-18, 7:59 am |
|
Jan Vorbr=FCggen wrote:
>
> It makes clear what parts of a module are actually used (or intended to be
> used) and avoids cluttering the name space - i.e., symbols coming into sc=
ope
> that you don't want to have or even don't know of.
It can also make it easier to find where a procedure is defined. My
convention is to store module foo_mod in source foo.f90, so if I see
code "use foo_mod, only: bar" I know where to find the version of
procedure "bar" used in the code.
| |
|
| Matthias M=F6ller wrote:
> USE crs7_operations, ONLY : matmul7 =3D> matrix_vector_multiplication
> USE crs9_operations, ONLY : matmul9 =3D> matrix_vector_multiplication
>
> That is, both modules provide exactly the same methods but differ, e.g.,
> in the way of implementation (performance, safety) and/or data types. If
> you omit the ONLY statement then you will have to rename ALL methods by
> hand. Is this right?
As I remember, you can omit the ONLY and still have a rename-list, say:
USE crs7_operations, matmul7 =3D> matrix_vector_multiplication
USE crs9_operations, matmul9 =3D> matrix_vector_multiplication
| |
| Matthias Möller 2006-07-18, 7:59 am |
| jwm schrieb:
> Matthias Möller wrote:
>
> As I remember, you can omit the ONLY and still have a rename-list, say:
>
> USE crs7_operations, matmul7 => matrix_vector_multiplication
> USE crs9_operations, matmul9 => matrix_vector_multiplication
>
Yes, I think so. However, the compiler will complain if modules
crs7_operations and crs9_operations have, say, 200 routines with the
same name which you have to rename by hand.
Matthias
| |
| Richard Maine 2006-07-18, 7:01 pm |
| On Mon, 17 Jul 2006 23:58:53 -0700, Matthias M=F6ller wrote
(in article <e9i0re$i0c$1@nx6.HRZ.Uni-Dortmund.DE> ):
> my colleague reported that the time for
> compiling (ifc,g95) the code drastically increases when USE ... ONLY is
> employed.
That puzzles me. I'd expect that, if anything, the ONLY ought to help
speed compilation by lowering the number of symbols being dealt with
(only likely to be relevant of there are a large number of symbols in
the module). I'd swear I recall suggestions to add ONLY specifiers in
order to speed up compilation in early implementations of DVF.
I'll note (and hope that nobody is reading :-)) that I rarely use ONLY
in my own codes. I know that many people here recommend the use of ONLY
as a good style. Some are quite emphatic about it; others less so.
While I can see the arguments for a style that uses ONLY, I don't
actually do that myself and the arguments haven't convinced me to
change my style. I won't argue that you should avoid ONLY. But I will
claim, in self justification, that it is ok to do so.
No, I won't argue the point. We already had those arguments. As I said,
my position on this is one of accepting that multiple style choices are
reasonable on this matter. I don't have any interest in convincing
others that they must adopt my own style choice in the matter, and I
know that they aren't going to convince me that my choice is horrid (I
already saw the arguments, and they don't convince me). So there seems
no point in debating.
--
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
| |
|
| Hi,
I find "USE,ONLY" to be *VERY USEFUL* in making the code more readable
and
making it more structured.
By using "use only" we can define only those
subroutines/functions...etc that are used
from that module. In a single glance, you can know that out of the 50
or more
subroutines defined in the module, which routines are begin used .
Needless to say, its a great help while you are debugging large codes.
Moreove I feel the use of "ONLY" goes well with the concept of OOPS. If
the
subroutine doesn't need all the routines in the module file.....why
should they be visible to the subroutine.
--Ari
Matthias M=F6ller wrote:
> Hi,
>
> I was asked by a colleague what is the great benefit of the ONLY
> qualifier in combination with the USE statement. Well, I think together
> with 'renaming' it enables you to do something like
>
> USE crs7_operations, ONLY : matmul7 =3D> matrix_vector_multiplication
> USE crs9_operations, ONLY : matmul9 =3D> matrix_vector_multiplication
>
> That is, both modules provide exactly the same methods but differ, e.g.,
> in the way of implementation (performance, safety) and/or data types. If
> you omit the ONLY statement then you will have to rename ALL methods by
> hand. Is this right?
>
> Can you image other situations in which the ONLY qualifier brings
> additional advantages.
>
> I need some 'advantages' because my colleague reported that the time for
> compiling (ifc,g95) the code drastically increases when USE ... ONLY is
> employed.
>=20
> Thanks in advance,
> Matthias Moeller
| |
| robert.corbett@sun.com 2006-07-18, 7:01 pm |
|
Richard Maine wrote:
> On Mon, 17 Jul 2006 23:58:53 -0700, Matthias M=F6ller wrote
> (in article <e9i0re$i0c$1@nx6.HRZ.Uni-Dortmund.DE> ):
>
>
> That puzzles me. I'd expect that, if anything, the ONLY ought to help
> speed compilation by lowering the number of symbols being dealt with
> (only likely to be relevant of there are a large number of symbols in
> the module). I'd swear I recall suggestions to add ONLY specifiers in
> order to speed up compilation in early implementations of DVF.
I can easily imagine why using ONLY might make compilation slower.
When ONLY is not present, the compiler might simply dump all of the
symbols into the symbol table. With ONLY, the compiler must look up
each symbol in the module file individually. If the compiler used
linear scan to find the symbols and there were a lot of symbols, the
time to look up the symbols would grow quadratically, while the time
to simply dump the symbols into the symbol table would grow linearly.
Bob Corbett
| |
| James Giles 2006-07-18, 7:01 pm |
| robert.corbett@sun.com wrote:
> Richard Maine wrote:
....
>
> I can easily imagine why using ONLY might make compilation slower.
> When ONLY is not present, the compiler might simply dump all of the
> symbols into the symbol table. With ONLY, the compiler must look up
> each symbol in the module file individually. If the compiler used
> linear scan to find the symbols and there were a lot of symbols, the
> time to look up the symbols would grow quadratically, while the time
> to simply dump the symbols into the symbol table would grow linearly.
I would still have expected the the form with ONLY to be faster.
Consider:
USE A; USE B; USE C;
...
X = Y + Z
Since there's no ONLY clauses, you have to look up the symbols
X, Y, and Z in all three modules to find out how they're declared
and, if they're inherited through more than one of the above, that
those repititions are actually consistent (that is, the symbol is
actually ultimately always inherited from the same module).
With ONLY clauses you would have only have had to look up
the symbols in the place you *knew* they came from.
You are evidently visualizing that a compiler must build a separate
version of a module's symbol table for each USE of the module.
I don't see why that would be necessary.
--
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
| |
| robert.corbett@sun.com 2006-07-18, 9:58 pm |
|
James Giles wrote:
> robert.corbett@sun.com wrote:
> ...
> I would still have expected the the form with ONLY to be faster.
> Consider:
>
> USE A; USE B; USE C;
> ...
> X = Y + Z
>
> Since there's no ONLY clauses, you have to look up the symbols
> X, Y, and Z in all three modules to find out how they're declared
> and, if they're inherited through more than one of the above, that
> those repititions are actually consistent (that is, the symbol is
> actually ultimately always inherited from the same module).
> With ONLY clauses you would have only have had to look up
> the symbols in the place you *knew* they came from.
>
> You are evidently visualizing that a compiler must build a separate
> version of a module's symbol table for each USE of the module.
> I don't see why that would be necessary.
It is not necessary. It is the easiest way to do it. I would be
interested
in knowing if there are any compilers that don't dump the symbols
from a module into the symbol table at the point of the USE
statement.
Bob Corbett
| |
| James Giles 2006-07-19, 4:00 am |
| robert.corbett@sun.com wrote:
> James Giles wrote:
...
>
> It is not necessary. It is the easiest way to do it. I would be
> interested
> in knowing if there are any compilers that don't dump the symbols
> from a module into the symbol table at the point of the USE
> statement.
I don't think your answer is responsive to my statement above.
Yes, when you USE a module, you copy its symbol table into
the local one. But the comment I made is that you appear to
be assuming that you have to modify the module's symbol
table (at least, if there's an ONLY clause). Why? That
doesn't look like the easiest way, or even among the easier
ways.
Consider the following thought experiment. Suppose you have
a program unit with no USE statements:
X = Y + Z
PRINT *, Z
END
You parse this program unit, building symbol table entries
for X, Y,and Z as you go and marking them as undeclared.
Then following the rules of Fortran, you implicitly change
their symbol table entries after the parse is done (but before
code generation, or optimizations, etc.) to their IMPLICIT
type based on their names.
Now, suppose you change the code to:
USE A; USE B; USE C
X = Y + Z
PRINT *, Z
END
You parse this program unit, building symbol table entries
for X, Y,and Z as you go and marking them as undeclared.
The, after the parse you augment the symbol table with
separate blocks of symbols corresponding to the modules
A, B, and C. And you additional blocks of symbols for any
modules USEd in turn by A, B, and C (copies of those
will actually be in the .mod files for A, B, andC). Then
you have to look for the symbols X, Y, and Z in those
additional blocks of symbols you now have. And, you can't
just stop when you find an appropriate entry. You have to
look through *all* possible inheritence paths to ensure they
all lead ultimately to the same declaration in the same block
of symbols (this corresponding to the same MODULE).
(If any of the USEs in the modules themselves have ONLY
clauses, that fact will be in the "local" block of symbols
for that module.)
You now mark the *local* symbol table entries for X, Y, and
Z with the fact they are from a module and indentify the
block of symbols (their MODULE of ultimate origin) and the
offset into that block. If the symbols were not in any of the
MODULEs, you mark them with the appropriate implicit
type.
Now, suppose you modify the code to the following:
USE A, only: X; USE B, only: Y; USE C
X = Y + Z
PRINT *, Z
END
Here the steps are identical to those above except for the
search for the symbols in the additional blocks of symbol
table entries. For those the search paths are fewer and
(if all USEs in the modules themselves also have ONLY
clauses) are very specific. Note that here even Z can
only be from one place (MODULE C) since it's not on
the ONLY list for MODULEs A and B. The more specific
you are with the ONLY clauses, the faster the search will
be. I can't think of any significant work that ONLY clauses
*add* to the process. Indeed, there are really very few
other differences beyond the searches.
--
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
| |
| glen herrmannsfeldt 2006-07-19, 4:00 am |
| James Giles wrote:
(snip of explanation of parsing using modules)
> Now, suppose you modify the code to the following:
>
> USE A, only: X; USE B, only: Y; USE C
> X = Y + Z
> PRINT *, Z
> END
> Here the steps are identical to those above except for the
> search for the symbols in the additional blocks of symbol
> table entries. For those the search paths are fewer and
> (if all USEs in the modules themselves also have ONLY
> clauses) are very specific. Note that here even Z can
> only be from one place (MODULE C) since it's not on
> the ONLY list for MODULEs A and B. The more specific
> you are with the ONLY clauses, the faster the search will
> be. I can't think of any significant work that ONLY clauses
> *add* to the process. Indeed, there are really very few
> other differences beyond the searches.
I suppose speed could be one reason(*), but consider that one
may have modules written by other people. It might be that
some variable names conflict with each other, or with variables
already in the code. To resolve conflicts, ONLY would seem a
good solution.
It seems that ONLY also allows one to use a different local name
than the name in the module, even more useful in the case of conflicts.
(Somewhat like what could be done with COMMON, using different
variable names in different routines to avoid conflicts and confuse
others reading the code.)
(*) In one manual for the IBM Fortran H compiler, which uses trees
for the symbol table, one for each possible (1 to 6) variable length,
it is suggested that to speed up compilation one should distribute
variable names equally between the different lengths.
-- glen
| |
| James Giles 2006-07-19, 4:00 am |
| glen herrmannsfeldt wrote:
....
> I suppose speed could be one reason(*), but consider that one
> may have modules written by other people. It might be that
> some variable names conflict with each other, or with variables
> already in the code. To resolve conflicts, ONLY would seem a
> good solution.
Exactly my point the last time the "who should USE ONLY"
debate arose. Here I was trying to examine the claim that
ONLY is more costly. I don't think it should be (I think the
contrary).
> It seems that ONLY also allows one to use a different local name
> than the name in the module, [...]
You can use renaming without ONLY.
--
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
| |
| Brooks Moses 2006-07-19, 4:00 am |
| Matthias Möller wrote:
> Jan Vorbrüggen schrieb:
>
> This is what my colleague measured
>
> ifort 9.1.038 (32bit):
> 0' 1'' nur mit use
> 1'20'' mit use only
>
> ifort 9.1.038 (64bit):
> 0' 1'' nur mit use
> 1'13'' mit use only
>
> g95 2006-07-11:
> 0' 0.3'' nur mit use
> 0' 6'' mit use only
Those numbers, particularly for ifort, are pretty drastic. While the
ONLY clause is useful in some styles, I don't think it's useful enough
to be worth that sort of time increase -- if the results for larger
programs remain proportional.
However, with something that drastic, I also a rather dubious of the
results -- particularly without seeing the actual codes that were
tested. (Is your colleague perhaps indiscriminately putting every
single symbol from every module into its USE clause, creating huge long
lists? Is he sure he's compiling from scratch both times?)
Or, alternately, are the codes small enough that you could post them
here? A 1-second compile time out of ifort would seem to indicate a
pretty small program; on my system, it doesn't even seem to load the
compiler that fast.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Mark Westwood 2006-07-19, 4:00 am |
| Hi
Well, I did the obvious, and timed the compilation of one of our codes.
Using Portland Group compiler v6.x on Linux:
a) with USE ONLY -> compilation time 36s
b) replace USE ONLY by USE in main program -> 36s
c) replace all USE ONLY I could without rewriting large portions of
code -> 36s
OK, I admit I've just dropped the fractions of seconds, and I admit
that a 36s compile time isn't very long.
For me (c) is the killer reason for using USE ONLY -- I find it much
easier to integrate old code into new programs this way, I have some
old source files which I don't want to touch (they ain't broke, I ain't
going to fix them) but which would provide way too many strangely named
variables (such as 'i' or 'n' or 'e') if I wasn't fussy about which
ones I import.
And, to all those who constructed elaborate arguments why a compiler
might work more slowly when USE ONLY is specified -- can you fit your
explanations to this new set of data ?
Regards
Mark Westwood
Parallel Programmer
Matthias M=F6ller wrote:
> Hi,
>
> I was asked by a colleague what is the great benefit of the ONLY
> qualifier in combination with the USE statement. Well, I think together
> with 'renaming' it enables you to do something like
>
> USE crs7_operations, ONLY : matmul7 =3D> matrix_vector_multiplication
> USE crs9_operations, ONLY : matmul9 =3D> matrix_vector_multiplication
>
> That is, both modules provide exactly the same methods but differ, e.g.,
> in the way of implementation (performance, safety) and/or data types. If
> you omit the ONLY statement then you will have to rename ALL methods by
> hand. Is this right?
>
> Can you image other situations in which the ONLY qualifier brings
> additional advantages.
>
> I need some 'advantages' because my colleague reported that the time for
> compiling (ifc,g95) the code drastically increases when USE ... ONLY is
> employed.
>=20
> Thanks in advance,
> Matthias Moeller
| |
| Mark Westwood 2006-07-19, 4:00 am |
| Hi Bil
Thanks for the pointer to your F95 coding standards which I think are
excellent. But I have a question: why do they require that the first
executable statement in a sub-program should be 'continue' ?
Regards
Mark Westwood
Parallel Programmer
Bil Kleb wrote:
> Matthias M=F6ller wrote:
>
> Hello.
>
>
> We use it for evolving our software design by looking at the
> only patterns. For example, you may find that only a small
> subset of a given module actually gets used repeatedly, and
> gives one a candidate for splitting the module or moving
> the particular method to another module.
>
> ONLYs are part of our coding standard -- see website below.
>=20
> Regards,
> --
> Bil Kleb
> http://fun3d.larc.nasa.gov
| |
| Jan Vorbrüggen 2006-07-19, 8:02 am |
| > Thanks for the pointer to your F95 coding standards which I think are
> excellent. But I have a question: why do they require that the first
> executable statement in a sub-program should be 'continue' ?
I don't know for sure, but I can guess: This makes it crystal-clear to
both a human being and the compiler reading the code where the specifications
end and the exectuable statements begin. With statement functions and such,
it can be quite tricky to determine that point correctly. This just makes
it easier to do so.
Jan
| |
| Craig Powers 2006-07-19, 7:01 pm |
| Brooks Moses wrote:
>
> Or, alternately, are the codes small enough that you could post them
> here? A 1-second compile time out of ifort would seem to indicate a
> pretty small program; on my system, it doesn't even seem to load the
> compiler that fast.
On the Opteron cluster where I run my programs, most of the files
compile in well under one second. (The program subsequently takes a
good bit of time to link, thanks to ipo, but at that point any overhead
due to USE, ONLY should be out of the way.)
| |
| gary.l.scott@lmco.com 2006-07-19, 7:01 pm |
|
Jan Vorbr=FCggen wrote:
>
> I don't know for sure, but I can guess: This makes it crystal-clear to
> both a human being and the compiler reading the code where the specificat=
ions
> end and the exectuable statements begin. With statement functions and suc=
h,
> it can be quite tricky to determine that point correctly. This just makes
> it easier to do so.
>=20
> Jan
Maybe then we need a DECLARE/END DECLARE block structure??
| |
| John Harper 2006-07-19, 7:01 pm |
| In article <1153328117.828131.118360@75g2000cwc.googlegroups.com>,
<gary.l.scott@lmco.com> wrote:
>
>Maybe then we need a DECLARE/END DECLARE block structure??
>
Aargh. I hope that '??' == ':-)' above. The standard is complicated
enough already. DECLARE is superfluous, as declarations must always
be at the beginning of a program unit. Even in f66 you could say
C END DECLARE
and the NAG Fortran 77 program library examples do the equivalent:
* .. Executable Statements ..
appears after the last declaration, data statement or common block.
(I think they always avoid having data statements among executables.)
In modern free source form just replace that * or C by !
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| ejko123@yahoo.com 2006-07-19, 7:01 pm |
|
James Giles wrote:
> glen herrmannsfeldt wrote:
> ...
>
>
> You can use renaming without ONLY.
The ONLY mechanism strikes me as clumsy. If modules
M1 and M2 both define the symbol X, it seems to me to be
much better if Fortran allowed one to say M1%X and M2%X to
disambiguate the two references. Renaming M2's X to,
say, Y, does not enhance understanding (especially if the
renaming isn't consistent between scoping units or if M1 also
happens to define a Y).
I think it would also be useful to have a construct like
USE, EXPLICIT :: M1
which would not dump M1's symbols into the current
scope but instead would require the prefix M1% in all
references to objects in M1.
--Eric
| |
| Gary Scott 2006-07-19, 10:00 pm |
| John Harper wrote:
> In article <1153328117.828131.118360@75g2000cwc.googlegroups.com>,
> <gary.l.scott@lmco.com> wrote:
>
>
> Aargh. I hope that '??' == ':-)' above.
Yes, you can just about assume that everything I post for the next
several months contains a smiley (a promotion is eminent (I think)).
The standard is complicated
> enough already. DECLARE is superfluous, as declarations must always
> be at the beginning of a program unit. Even in f66 you could say
> C END DECLARE
> and the NAG Fortran 77 program library examples do the equivalent:
> * .. Executable Statements ..
> appears after the last declaration, data statement or common block.
> (I think they always avoid having data statements among executables.)
> In modern free source form just replace that * or C by !
>
> -- John Harper, School of Mathematics, Statistics and Computer Science,
> Victoria University, PO Box 600, Wellington 6140, New Zealand
> e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
--
Gary Scott
mailto:garylscott@sbcglobal dot net
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
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| James Giles 2006-07-19, 10:00 pm |
| ejko123@yahoo.com wrote:
> James Giles wrote:
>
> The ONLY mechanism strikes me as clumsy. If modules
> M1 and M2 both define the symbol X, it seems to me to be
> much better if Fortran allowed one to say M1%X and M2%X to
> disambiguate the two references. Renaming M2's X to,
> say, Y, does not enhance understanding (especially if the
> renaming isn't consistent between scoping units or if M1 also
> happens to define a Y).
>
> I think it would also be useful to have a construct like
> USE, EXPLICIT :: M1
> which would not dump M1's symbols into the current
> scope but instead would require the prefix M1% in all
> references to objects in M1.
That's what my own language does (though the syntax is
M1..X and I don't have a USE keyword, but an IMPORT
instead). Rename is still useful in other ways, though
fewer. The syntax:
IMPORT M1: A, B, C
Allows you to write references to A, B, and C directly,
but all other symbols in M1 must be qualified:
A = M1..X
Similarly, an internal procedure that contains an IMPORT
statement with no module name is controlling the host association.
IMPORT : P, Q, R
This imports P, Q, and R by host association. Any other
symbols in the host must be qualified (with the host's name,
or with a special syntax form):
P = myhost..S
or
P = ..S
The last two mean the same thing. Not requiring the hostname
as a special syntax form is useful since internal procedures
might be written independently of any particular host and
INCLUDEd in various places to provide common operations
that are efficiently implemented (something you can't count
on with MODULE procedures).
--
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
| |
| robert.corbett@sun.com 2006-07-19, 10:00 pm |
|
James Giles wrote:
> robert.corbett@sun.com wrote:
> ...
>
> I don't think your answer is responsive to my statement above.
It was, but I think you might have misunderstood my original statement.
You said
I don't see why that would be necessary.
I said
It is not necessary.
I was agreeing with you.
In my posting to which you responded, I described one way
in which modules could be implemented that would show the
behavior the O.P. described. I did not say that was the only
way in which modules could be implemented.
Bob Corbett
| |
| Brooks Moses 2006-07-19, 10:00 pm |
| Craig Powers wrote:
> Brooks Moses wrote:
>
> On the Opteron cluster where I run my programs, most of the files
> compile in well under one second. (The program subsequently takes a
> good bit of time to link, thanks to ipo, but at that point any overhead
> due to USE, ONLY should be out of the way.)
Hmm. The one that I was recently compiling is (rough guess) 1000 lines
of code, and took about five seconds. Admittedly, that's with all of
the sub-files included via include statements at the top of the main
program file, rather directly as source files in the "project", so it's
the whole thing at once.
Also, I suppose I should remember that my computer is a little slower
than most people's. :)
- Brooks (who does a lot of his development on a 333MHz laptop, but
those times are from a 1.1GHz desktop.)
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Matthias Möller 2006-07-20, 8:00 am |
| > However, with something that drastic, I also a rather dubious of the
> results -- particularly without seeing the actual codes that were
> tested. (Is your colleague perhaps indiscriminately putting every
> single symbol from every module into its USE clause, creating huge long
> lists? Is he sure he's compiling from scratch both times?)
I don't think so. Actually, only used "USE ONLY" on one module for
testing purposes and already observed the drastic increase of compile time.
> Or, alternately, are the codes small enough that you could post them
> here? A 1-second compile time out of ifort would seem to indicate a
> pretty small program; on my system, it doesn't even seem to load the
> compiler that fast.
Well, it is some larger project. But my colleague will prepare some
small sample program.
Matthias
| |
| Ian Bush 2006-07-20, 8:00 am |
| Craig Powers wrote:
> Brooks Moses wrote:
>
> On the Opteron cluster where I run my programs, most of the files
> compile in well under one second. (The program subsequently takes a
> good bit of time to link, thanks to ipo, but at that point any overhead
> due to USE, ONLY should be out of the way.)
Without ipo how long does each of the compiles take ? I'm not a compiler
guy, but I can see that it might be possible that if ipo is not on each file
has to have operations performed on it that would otherwise be performed during
the link stage.
Also do you gain much from interprocedural analysis/optimization ? I've never
seen very much,
Ian
| |
| Matthias Möller 2006-07-20, 7:00 pm |
| Hi,
first of all I'd like to thank all of you for this fruitful discussion.
My colleague did some more testing. To conclude, it seems that the
drastic increase of compile can only be observed for the Ifort compiler.
Here is what my colleague posted:
We did some more tests with the code with which we stumbled across the
problem of drastically increased compile times when using 'use, only'.
The conclusion at the beginning: the drastic increase in compile time
when using 'use, only' seems to be confined to the Intel Fortran
Compiler and DEC/HP/Compaq Fortran Compiler. Recent versions of Intel
Fortran Compiler are doing better in comparison to 8.x series, but
compile times still increase by significant factor (factor depending on
number of symbols named in 'use,only' statements.
-- details: --
Before trying to distil a small sample code, I scrutinised the
conditions under which compilation times for "use, only" statements
drastically increase. It did this with the code I used when I stumbled
across the problem initially.
Some statistics (to illustrate that a compiler should benefit from 'use,
only' instead of plain 'use' statements as the amount of symbols needed
in the module concerned is significantly less than the number of
available symbols via plain 'use'):
Project consists of
* 161447 code lines (excluding empty and comment-only lines)
* 42 separate modules
and a few third party libraries.
The top-most module, the application itself, makes use of 19 modules
which declare in total 122 functions, 539 subroutines, 37 type blocks
and 513 constants. All modules besides the top-most one use plain 'use'
statements only.
Below you'll find the timings to compile that single module, either with
plain 'use' statements or with 'use, only' selecting 58 out of those 661
functions/subroutines, 3 type blocks and 13 constants explicitly.
For the timings, the complete project has been re-compiled every time
from scratch omitting any optimisation step (i.e. -O0 -g). Timings done
with unix command 'time'. Timings are 'user time'. Timings are average
of 3 subsequently repeated compile commands.
platform + compiler use <foo> use <foo>, only: <bar>
pc-athlonxp-linux32 0m1.196s 2m38.192s (!)
2 GHz
ifort 9.1.038
pc-athlonxp-linux32 0m1.198s 2m44.343s (!)
2 GHz
ifort 9.0.030
pc-athlonxp-linux32 0m1.371s > 2 hours (compilation manually
aborted)
2 GHz
ifort 8.1.021
pc-athlonxp-linux32 0m6.274s 0m3.893s
2 GHz
G95 (Jul 17 2006)
pc-athlonxp-linux32 0m16.873s 0m15.874s
2 GHz
GFortran 4.1.1
pc-opteron-linux64 0m0.840s 0m0.830s
2.6 GHz
pathscale 2.4
pc-opteron-linux64 0m1.940s 0m1.900s
2.6 GHz
pgi 6.1.5
pc-opteron-linux64 0m1.360s 0m1.370s
2.6 GHz
SunStudio 11alpha
sun4u-sparcv9-sunos 0m2.740s 0m2.760s
1 GHz
SunStudio 11
alpha-ev6-osf1 0m10.939s 2m51.549s (!)
823 MHz
Compaq Fortran X5.4A-1684
Bye,
Matthias
| |
| Craig Powers 2006-07-20, 7:00 pm |
| Ian Bush wrote:
> Craig Powers wrote:
>
>
>
>
> Without ipo how long does each of the compiles take ? I'm not a compiler
> guy, but I can see that it might be possible that if ipo is not on each file
> has to have operations performed on it that would otherwise be performed during
> the link stage.
My presumption is that -ipo results in, at minimum, an intermediate
representation being output as the .o files. I presume that the likely
overhead to doing USE, ONLY would be incurred by that point.
Without -ipo, I don't think any of the files takes longer than two
seconds to compiler, but it's inconvenient to measure.
> Also do you gain much from interprocedural analysis/optimization ? I've never
> seen very much,
On the order of a half a second on a ca. 20 second timing run, which
performed tasks substantially the same as my real simulations. Not
huge, but enough to be worthwhile for simulations taking a day or more
to complete.
| |
| Jan Vorbrüggen 2006-07-21, 3:59 am |
| > Yes, you can just about assume that everything I post for the next
> several months contains a smiley (a promotion is eminent (I think)).
I'm sure it's for eminent work, but do hope it is imminent.
Jan
PS: What, they promote old farts like us instead of making them redundant?
Whatever has happened to shareholder value!?
|
|
|
|
|