Possible Code Performance Disparity using "parameter"

[John L. Males]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve,

Thank you very much for your reply.

I am not a compiler developer or like, but have some sense from
days gone by of compilers and assemblers I often fixed bugs in
or made major changes to.  Suffice to say I know alot has
changed since then.

I know the "parameter" statement is as you stated when reporting
this as a possible issue.  I believe some of the possible
reasons you have stated may be the reason for the difference in
run time of the generated code.  What I am not so sure is if
the nature of the difference, i.e. the variable that is still
only used as a constant and never changed after reading the
value from a command line argument is sufficient to justify the
difference in code generation.

The code in the program that consumes the CPU time is actually
very simple.  The code is a unique algorithm of 19 lines - one
"do while" with three serial (unnested do's) within the "do
while" of which one "do" has an "if" statement within. This
noted code is the meat of the program.  Following this noted
code the program prints a line or two of a couple numbers then
exits.  The logic before the noted code is just to print some
static text, the values of the constants and prime a very small
array with values. The constant/variable in question is
set/read from the command line prior the noted code that is the
problem depending on if it is a constant or variable.

I will try to create a sample test program that will duplicate
the problem. I know and understand code that demonstrates the
problem will enable you to better access the concern and if
there is a possible opportunity to improve the gcc/gfortran
code generation.

I will see if I can find other Fortran compilers which I can
try with my code as well sample code I will try to write that
duplicates the issue.

Do I reply back to you and cc <mailtofortran@gcc.gnu.org> or do
I just reply to <fortran@gcc.gnu.org> with the sample test code
attached?


Regards,

John L. Males
Toronto, Ontario
Canada
12 March 2012 20:45
<mailto:jlmales@gmail.com> 


==============================================================
2012-03-12 20:18:17.015826368-0400-EDT

12 Mar 20:18:17 ntpdate[21310]: ntpdate 4.2.6p2@1.2194-o Sun
Oct 17 13:35:14 UTC 2010 (1)

12 Mar 20:18:29 ntpdate[21315]: step time server 199.212.17.35
offset 0.003710 sec

Linux 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012

Modified Debian GNU/Linux 6.0.3 (squeeze)
Planning, Upgrade, Modifications from Highly modified
Debian 4.x Etch


Message replied to:

Date: Mon, 12 Mar 2012 15:18:09 -0700
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: "John L. Males" <jlmales@gmail.com>
Cc: fortran@gcc.gnu.org
Subject: Re: Possible Code Performance Disparity using
"parameter"


> On Mon, Mar 12, 2012 at 06:03:11PM -0400, John L. Males wrote:
> > 
> > Any thoughts or comments with regards to this discovery?
> > 
> 
> Without seeing the code, one can say very little.
> 
> You do realize that the PARAMETER attribute in a type
> declaration statement makes an entity a named constant
> and not a variable.  When it is a named constant, gfortran
> will replace the entity by the actual value, which may
> permit constant-folding and other optimizations (such
> as hositing a (sub)expression out of a loop).  Depending
> on how complicated the code is and how you use the 
> entity when it is a variable, the generated code may
> actually be read its value from memory on each iteration.
>  
> -- 
> Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk9emJgACgkQ+V/XUtB6aBBlGwCg1RRhxWQbetQmqqaKrjnsRBC9
/pEAoJtMt12/1IBO2k/qUhX/hep/swdY
=vnfn
-----END PGP SIGNATURE-----