Re: scope and/or parameters (beginner)

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <7f1jce$nt4$1@nnrp1.dejanews.com>,
  czgrr <czgrr@my-dejanews.com> wrote:
> I use ObjectAda Professional Edition version 7.1.1.543,
> on Windows NT 4.0 with 128MB memory. Output was...
>
> 3.67944E+04 Calling global...
> 3.67945E+04 Calling local...
> 3.68065E+04 Finished.
>
> That is, 0.1 second (to nearest 0.1 second!) to do the
> global verison, 12.0 seconds to do the local version.

And that statement is ALL you can conclude from this
experiment, namely that on the particular compiler you
used, with this particular program, you get these
particular results. You can't conclude anything general
about even your particular implementation, let alone about
local and global variables in general.

There is absolutely NO reason to see any difference between
the local and global array accesses here, except that of
course a good compiler should completely and easily
eliminate the code for the local version all together,
since the array is dead, and it is easy to see that it is
dead.

You do have a dynamic frame in your local procedure (I
hope you understand the fundamental and critical difference
between a dynamic or static local frame), and this means
that there is a dynamic stack check in the local version
that is probably avoided in the global version.

GNAT gives the following results for this program:

 3.12079E+04 Calling global...
 3.12079E+04 Calling local...
 3.12079E+04 Finished.

i.e. neither case takes detectable time, which is what
you would expect. This particular test is deeply flawed
in several respects.

a) As I noted above, the local version is far too easy
to optimize away.

b) Even the global version is too attackable by an
optimizer.

c) linking the size of the array to the number of test
loops is conceptually wrong.

d) using calendar and time of day to measure CPU
performance is fundamentally flawed.

e) Your can't tell whether the result of your code is
from the call or the array access, so it is hard to
interpret the results.

f) You have not considered issues of optimization issues
etc in deciding how to run this benchmark.

We find that people who try to run their own timing tests
almost always make these kinds of mistakes. Writing
meaningful benchmark tests is VERY tough. Almost always
when someone reports some anomoly with GNAT timing from
some little test program they have written, the anomoly
is a direct consequence of an incorrectly written test.

So how come you saw such bizarre results from your
test run with Object Ada? There could be many reasons.

1) You have run into some strange anomoly in code
generation. This seems unlikely, but is possible,
12 seconds for the local case makes no sense. Let's
do some quick calculations:

   You are calling a routine only 100,000 times. In 12
   seconds, this means 10,000 calls/second, which on a
   slowish PC (you did not give the analysis platform)
   which gives you at least 200,000,000 instructions
   per second, probably more, something like 20,000
   instructions per call.

That of course is completely absurd. The expected time
for this execution should be in the region of 10-50
instructions per call at most, even with lousy
optimization, so you should be talking something like
1000 times that speed or in the range of 10-20
milliseconds for your test.

Nevertheless an anomoly is always possible. Suppose for
example, that the stack check for the local case involved
a system call to find the current task to get the stack
limit. That's unimaginably horrible, but strange things
have been seen.

You can of course look at the assembly language generated
by your compiler, to see if there is some such nasty
anomoly, but I would doubt this is the reason

2) Your setup or observations are flawed in some way.

3) The calendar mistake cost you meaningful results

4) Something else completely unrelated is wrong

The point is that you cannot draw ANY conclusions from a
test that is poorly written, and whose results you cannot
explain when they clearly make little sense.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own