Parameters in Optimization...
Brad Dominik
I have a question that pertains to Microsoft Fortran Powerstation 4.0
Professional and Digital Visual Fortran 5.0. I am writing a program that
is very compute intensive - taking ~8 hours to run on a Pentium Pro 200.
The calculations involve using several constants - that is, variable that
will not change during the program run, but that I need the ability to
change at compile time if needed. Therefore, I have defined these
constants as parameters.
My question regards the compiler optimizations regarding parameters. When
the program is compiled, are the parameters substitued for hard coded
numbers? So, if I have a loop that runs a certain number of times,
specified by a parameter, is the loop upper limit then hard coded into the
program in a way that allows the compiler to peform loop optimization?
How about intermediate calculations? If I multiple a*b*c*D, where a, b, &
c are parameters, but D is a variable, does the compiler calculate (a*b*c)
and then hard code the resultant into the code? I am asking because, for
example, this number will not change throughout program run, but will be
called many thousands of times. The speed would increase if the resultant
value were hard coded - it would eliminate two multiplication steps. (I
understand that I could manually calculate a*b*c and hard code it myself,
but it makes it much more difficult to maintain the code.)
Thanks,
Brad
bsd...@psu.edu
Craig Burley
"Brad Dominik" <bsd...@psu.edu> writes:
> The calculations involve using several constants - that is, variable that
> will not change during the program run, but that I need the ability to
> change at compile time if needed. Therefore, I have defined these
> constants as parameters.
>
> My question regards the compiler optimizations regarding parameters. When
> the program is compiled, are the parameters substitued for hard coded
> numbers? So, if I have a loop that runs a certain number of times,
> specified by a parameter, is the loop upper limit then hard coded into the
> program in a way that allows the compiler to peform loop optimization?
>
> How about intermediate calculations? If I multiple a*b*c*D, where a, b, &
> c are parameters, but D is a variable, does the compiler calculate (a*b*c)
> and then hard code the resultant into the code? I am asking because, for
> example, this number will not change throughout program run, but will be
> called many thousands of times. The speed would increase if the resultant
> value were hard coded - it would eliminate two multiplication steps. (I
> understand that I could manually calculate a*b*c and hard code it myself,
> but it makes it much more difficult to maintain the code.)
Most good compilers do such substitutions.
By the way, you (and all Fortran programmers) should know that in the
_world_ of Fortran, PARAMETERs, aka named constants, are _not_ the
same as variables that hold a single value.
For example, these two chunks of code are _not_ equivalent:
PROGRAM CHUNK1
DOUBLE PRECISION D
V = 0.1
D = 2D0
PRINT *, D * V
END
PROGRAM CHUNK2
DOUBLE PRECISION D
PARAMETER (V = 0.1)
D = 2D0
PRINT *, D * V
END
Within the confines of the Fortran standards (FORTRAN 77 and Fortran 90),
the above two programs _are_ equivalent.
However, many Fortran compilers, and many programmers using them, see
constants (whether named or literal) as fundamentally different than
variables.
In particular, CHUNK2 will be interpreted by many compilers as if it
was equivalent to:
PROGRAM CHUNK3
DOUBLE PRECISION D, V
PARAMETER (V = 0.1D0)
D = 2D0
PRINT *, D * V
END
(And, some compilers that interpret CHUNK1 and CHUNK2 the same way would
interpret the following differently:
PROGRAM CHUNK4
DOUBLE PRECISION D, V
V = 0.1
D = 2D0
PRINT *, D * V
END
That's because they interpret literal constants differently than named
constants.)
Specifically, how constants (including named constants) are interpreted
(converted to internal form, usually binary floating-point, such as IEEE)
depends on their context.
One effect of this difference is that you cannot simply replace all
occurrences of a variable in your program with an "equivalent" named
constant -- because, in many popular dialects of Fortran, there's no
such thing as a named constant that is equivalent to an arbitrary variable
(though in FORTRAN 77 and Fortran 90, "PARAMETER" does the trick).
(That's too bad, since it's exactly the sort of replacement that promotes
better programming, leading to more maintainable code.)
Another effect of this difference is that the _world_ of Fortran (not just
the standards) has no such thing as a variable that is defined to a
single value before program execution and is explicitly not permitted
to change during execution. Named and literal constants are thus _not_
at all in the same "camp" as variables, which programmers often view as
addresses of locations in memory -- they are, instead, strings that are
substituted as appropriate in each context in which they appear, and as
such are somewhat like macros in a preprocessor (e.g. cpp's
`#define PI 3.14159'). (The Fortran standards basically permit them
to be viewed in either light.)
So far, in designing GNU Fortran (g77), I've chosen the standard's
view that a constant (named or literal) is interpreted based only on
its content, not on its context. However, I might change g77 in the
future to conform with the UNIX f77 "standard", called "widest-need
evaluation", and provide an option to get the old behavior (and maybe
another option or two to get other behaviors) -- but only once I'm
sure I'll get all the details right (and I still don't have detailed
specs on all these details). It's much easier to explain the standard
(and current g77) treatment to someone and have them understand all the
implications, though the "widest-need evaluation" approach does provide
more "intuitive" behavior in a variety of cases (as illustrated by
CHUNK2 above, which, in isolation, would seem to properly be interpreted
as automatically converting 0.1 to 0.1D0 before interpreting it for
the multiplication with D). (The problem of g77 making changes such
as this to its default behavior is a significant one -- for the time
being, it's still in "beta test", officially, but such changes would
need to be _very_ widely announced.)
This difference will become even more pronounced in the future, as
will other differences in mind-set between various Fortran camps
(for example, functions with side effects). There seems to be litle
incentive in the Fortran community to either choose one model
and stick with it, or to collaborate on a new, more general, model
that would provide some means for the earlier models to be converted
to it.
--
"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Dan Nagle
Craig Burley wrote:
>
<snip>
>
> PROGRAM CHUNK2
> DOUBLE PRECISION D
> PARAMETER (V = 0.1)
> D = 2D0
> PRINT *, D * V
> END
>
> Within the confines of the Fortran standards (FORTRAN 77 and Fortran 90),
> the above two programs _are_ equivalent.
>
> However, many Fortran compilers, and many programmers using them, see
> constants (whether named or literal) as fundamentally different than
> variables.
>
> In particular, CHUNK2 will be interpreted by many compilers as if it
> was equivalent to:
>
> PROGRAM CHUNK3
> DOUBLE PRECISION D, V
> PARAMETER (V = 0.1D0)
^^
Aren't Fortran 90 compilers forbidden to "extend the precision
of a constant"? I thought this was something "cleaned up"
with f90.
(And I seem to remember a long running debate in c.l.f between some
compiler folks and some users on this topic some years back...)
<snip>
> James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Cheers!
Dan Nagle dna...@erols.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxjunk added to fool mailer into posting articlexxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Craig Burley
Dan Nagle <dna...@erols.com> writes:
> Craig Burley wrote:
> > PROGRAM CHUNK2
> > DOUBLE PRECISION D
> > PARAMETER (V = 0.1)
> > D = 2D0
> > PRINT *, D * V
> > END
> >
> > Within the confines of the Fortran standards (FORTRAN 77 and Fortran 90),
> > the above two programs _are_ equivalent.
> >
> > However, many Fortran compilers, and many programmers using them, see
> > constants (whether named or literal) as fundamentally different than
> > variables.
> >
> > In particular, CHUNK2 will be interpreted by many compilers as if it
> > was equivalent to:
> >
> > PROGRAM CHUNK3
> > DOUBLE PRECISION D, V
> > PARAMETER (V = 0.1D0)
> ^^
> Aren't Fortran 90 compilers forbidden to "extend the precision
> of a constant"? I thought this was something "cleaned up"
> with f90.
F90 brings a little more clarity to the picture. My guess is that
there are _F90_ compilers that would print different results given
the above two programs, however.
Regardless of what the Fortran standards say, to lots of Fortran
programmers, it is still "intuitive" that the first program really
means the same thing as the second -- that the constant is intended
(by the programmer) to be interpreted as double-precision, even
though explicitly (according to the language) specifed as single
precision. (Or at least that a literal constant, e.g. `D * 0.1',
is intended to mean `D * 0.1D0'.)
Seems unlikely to me that a vendor of past F77 compilers would
bring out an F90 compiler that didn't emulate this behavior, else
they'd have to explain to their customers that, by default, their
F90 compiler would not necessarily produce the same results as their
F77 compilers on standard-conforming F77 code (which is, basically,
one of the major selling points of F90 in the first place).
Presumably as a nod to F90 itself, most or all F90 compilers at
least provide an option to enable the stricter "spirit" of that
standard, e.g. by turning off context-sensitivity for constants
(switching from widest-need evaluation to strict evaluation).
> (And I seem to remember a long running debate in c.l.f between some
> compiler folks and some users on this topic some years back...)
Yup. My recollection of the conclusion/consensus is that, while F77
sorta and F90 really-sorta says context-sensitive interpretation of
constants is forbidden, they don't actually mandate a consistent
interpretation of constants due to not specifying precision (leaving
it up to the implementation).
So, the standards do not even mandate that
PRINT *, 0.1 - 0.1
prints 0.0, because they don't mandate that the approximation
used internally for the _first_ 0.1 is equal to that used internally
for the _second_.
So, a vendor can claim standards conformance on the basis that the
"extra bits" they tack on during a conversion from single to double
precision aren't mandated to be zero, so the fact that the bits they
tack on "happen" to be exactly what you'd get if you specified the
constant in double precision in the first place doesn't really make
their implementation non-conforming.
And, as has been basically told me by an advocate for at least one
major Fortran-industry vendor, "it doesn't matter to us what the standard
says about this -- we're doing it the right way". In fact, from this
person, and from a few others, I've gotten the distinct impression
that the sole purpose of the Fortran standardization effort is to
provide a basis for vendors to dismiss customer complaints about
improper operation, but rarely (if ever) to give customers a basis
to complain about vendor-product failures, especially in areas like
this -- where the vendor provides a feature that changes the
interpretation of standard-conforming code as part of a "feature"
providing more "intuitive" behavior.
Not that I agree with that particular viewpoint, but it's hard at this
point to see a practical alternative. I see enough major divisions in the
Fortran community that my interest in participating in standardization or
new-features design has gotten down pretty close to zero. IMO there is
no point continuing work to standardize, or improve, a language that
does not actually exist. When several major vendors offer compilers
that provide quite different interpretations for fairly vanilla code,
either different from each other or from what someone reading the
standard would expect, then there's not really a "Fortran" in the
sense I'm talking about (a well-defined language for expressing
computations, etc.).
Instead, it makes more sense to just forge ahead and do one's own
dialect of Fortran, as each of Sun, Digital, IBM, HP, SGI, and so on
all are doing, with only modest efforts made towards standardization
to cover stuff that is politically safe. (Lately I've added GNU to the
above list, having realized that I'd better either fish or cut bait,
and since I'm not gonna cut bait for nothin', .... For example, to
me it's not intuitive that REAL(Z), where Z is DOUBLE COMPLEX, returns
a REAL result, nor is it intuitive that it returns a DOUBLE PRECISION
result, so g77 does neither without further clarification in the code
or on the command line. g77 does provide REALPART(Z), where intuition
comes heavily down on the DOUBLE PRECISION side.)
Still, the standardization process is useful. People can write portable,
standard Fortran if they explicitly specify kinds for all "suspect"
constants (e.g. always specify 0.1E0 or 0.1D0 or 0.1_QUAD) and never
rely on functions' side effects being performed, among other things.
I guess my only ongoing contribution to the standardization effort is
to document for users where the lack of standardization exists in
practice, and explain what it truly means for user code. My frequent
posts here and, recently, to comp.compilers are not just for me to
say what I think and find out where disagreements exist so as to
learn from them -- I also hope to inspire a few more end users of
Fortran (and other languages) to think about what direction _they_ want
to take the language. The existence of free compilers like g77 is
just one reason to believe end users can directly influence the evolution
of a computer language -- actual understanding, or at least knowledge
of, language design concepts (what works, what doesn't, and why) is
another.
It'd be great, IMO, if the standards committee just decided what The
Right Way for Fortran code to express various constructs was, and
standardize that, letting vendors make their appropriate adjustments
over time. But I don't have much guidance to offer the standards
committee on what The Right Way is anymore, aside from my suggestions
along the lines of "well, it'd be nice to standardize what `D * 0.1'
actually means, and to what degree functions can have well-defined
side effects", and so on.