Declaring local variables inside loop

[Roedy Green]

Now my question is: does it matter that I declare tupleWithSecond
outside the loop? I have the impression that if I leave the first line
out and instead add ?FunctionInputTuple? before the third line, that a
new pointer space is created on the stack for each loop.

all slots on the stack frame for locals are allocated by a single
addition(subtraction) of the stack pointer on entering the method.

The advantage of putting them inside:

1. helps an optimiser. It know they can't be used in any way outside
the loop so it does not need to worry about saving them in ram in
case you jump out the loop.

2. helps others understand your code.

 

[Roedy Green]

try running the benchmark several times. the wobble! Other things
going on in the background out of your control interfere.

 

[Roedy Green]

That sounds as if it might be the 64-bit JMV running automatically in -server
configuration (which seems to optimise most, but not all, of the test away[*]).
Try giving it an explicit -client flag.

See http://mindprod.com/jgloss/benchmark.html
about the problems of the optimiser kicking at different times. You
want to measure "cold" or "warm" pre-post optimise.

 

[Roedy Green]

long start = System.currentTimeMillis();

System.nanotime gives you more accurate timing. You are going through
the same puzzles I have been the last week. You could benefit from my
discoveries, and you might even use my timing harness which by now is
getting snazzy -- it produces pretty HTML to post the results.

 

[Robert Klemme]

System.nanotime gives you more accurate timing.

I don't think so:

<quote>This method provides nanosecond precision, but not necessarily
nanosecond accuracy. No guarantees are made about how frequently values
change.</quote>

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime()

Kind regards

robert

 

[Robert Klemme]

Do you mean the differences in overall speed between -client and
-server ? If so then they are certainly /much/ smaller than the
order-of-magnitude differences I see for my test. (using 1.5 GHz,
WinXP sp1, jdk 1.4.2 or 1.5.0)

I was referring to the difference between execution times with a single VM
between several invocations of "local" and "outer" as well as between
average times for "local" and "outer". Sorry, if I wasn't clear enough.

I presume it's something to do with the different structures of our
test code in terms of what loops are in what methods, and which
methods get called /in/ loops.

If you refer to differences between -server and -client, then yes. That's
likely the case.

Cheers

robert

 

[Roedy Green]

I was referring to the difference between execution times with a single VM
between several invocations of "local" and "outer" as well as between
average times for "local" and "outer". Sorry, if I wasn't clear enough.

In a pedestrian interpreter you would expect no difference with the
variable declared locally in the outer block, but you would expect a
big slowdown if you made it a static or even worse, instance variable.

 

[Chris Uppal]

Roedy Green wrote:

System.nanotime gives you more accurate timing.

Yes, I /know/ !!

But that accuracy hardly matters when I'm taking an average from a
significant number of runs. Especially as the time we're measuring is
in the order of several seconds. The difference between millisecond or
microsecond (or whatever I would actually get from the "nano" time
clock) resolution is trivial in this case.

And I wanted the code to run on 1.4.

You are going through the same puzzles I have been the last week.

Nope. This how-to-do-tests-that-actually-measure-something is old hat.
Java adds a few twiddles, but they have been old hat too for several
years at least.

I'll admit that I didn't bother to estimate error bars for the results;
didn't seem worthwhile.

The issue is not how to measure the effect -- that's bleedin' obvious
-- the question is what is the cause, and how to pin that down as
tightly as possible.

-- chris

 

[Roedy Green]

I don't think so:

<quote>This method provides nanosecond precision, but not necessarily
nanosecond accuracy. No guarantees are made about how frequently values
change.</quote>

True, but in the real world this is implemented with a cycle counter
attached to the master clock. The actual source is You are not
interested in real world time, but clock cycle time to compare
algorithms. Pentium RDTSC provides subnanosecond resolution. Java
seem to do some sort of calibration to give you approximate
nanoseconds.


See http://mindprod.com/jgloss/time.html#RDTSC

 

[Robert Klemme]

True, but in the real world this is implemented with a cycle counter
attached to the master clock. The actual source is You are not
interested in real world time, but clock cycle time to compare
algorithms. Pentium RDTSC provides subnanosecond resolution. Java
seem to do some sort of calibration to give you approximate
nanoseconds.

Interesting insights! Thanks for that! I'd nevertheless rely on this
because it's not guaranteed documentation wise and because it's not needed
for the huge number of iterations.

robert

 

[Chris Uppal]

Roedy Green wrote:

True, but in the real world this is implemented with a cycle counter
attached to the master clock.

System.nanoTime() is implementation dependent.

On Windows boxes a 1.5 JVM uses the Win32 function
QueryPerformanceCounter() if that's available (afaik it normally
(always?) is). That has no defined resolution, you have to use
QueryPerformanceFrequency() to interpret the results. On the machine
I'm typing into that's 3,579,545 beats per second.

On Linux, it seems that a 1.5 JVM would like to use clock_gettime(),
but in fact (according to the comments) makes do with gettimeofday()
since clock_gettime() isn't necessarily monotonic. I don't know what
actual resolution gettimeofday() has but the result is reported in
microseconds so it can't be better than that.

On Solaris, it does something else again, apparently based on
gethrtime(). I don't know what resolution Solaris gethrtime() has. I
found one claim that it was 50 nanoseconds. OTOH, I've founds claims
that it's based on some sort of cycle count.

-- chris

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Roedy Green schreef:

In a pedestrian interpreter

What is this? Or what do you mean?

H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/tXge+7xMGD3itQRAmsLAJ9h7y6ioJwCAmxvQbP6laEdhLAddQCeKujc
roEy6LBodYRuUPd0w6rVYA0=
=Ptzw
-----END PGP SIGNATURE-----

 

[bugbear]

In general you should limit the scope of names, so
declaring the variable inside the loop is preferable.

Further, certainly for good 'C' compilers this style


loop1() {
variable1;
}

loop2() {
variable2;
}

allows the same storage (hopefully a register) to be used
for variable1 and 2.

BugBear

 

[Roedy Green]

What is this? Or what do you mean?

Something like the Java 1.0 JVM or a JVM you would find today inside
a cell phone. It interprets each byte code literally one at a time .
IT does not compilation to machine code.

 

[Roedy Green]

On Windows boxes a 1.5 JVM uses the Win32 function
QueryPerformanceCounter() if that's available (afaik it normally
(always?) is). That has no defined resolution, you have to use
QueryPerformanceFrequency() to interpret the results. On the machine
I'm typing into that's 3,579,545 beats per second.

What I would like to know is does Java make that adjustment for you
when you call nanotime, or it is up to you to calibrate the raw clock
cycle number? I suspect the later. This means that nanotime results
are only useful for comparing algorithms on the same hardware. If you
want to benchmark hardware you would have to use System.
currentTimeMillis();

 

[Biswajit Biswal]

Hi

A new pointer space will be created each time it enters the loop.
Compiler dont optimize the code at any case.

tnx
Biswajit Biswal

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Biswajit Biswal uitte de volgende tekst op 02/24/2006 05:16 PM:

Hi

A new pointer space will be created each time it enters the loop.
Compiler dont optimize the code at any case.

Are you sure? I would have thought something else from the answers I
got from others...

H.

--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEALQ2iOEY3xKMFEERAkc6AJ9oD22wV1ZwAfT+B49Tdp3WAKA6bgCgqVyV
f0XtUCYIb6m2D03bIuJb2YE=
=ceKP
-----END PGP SIGNATURE-----

 

[Patricia Shanahan]

What I would like to know is does Java make that adjustment for you
when you call nanotime, or it is up to you to calibrate the raw clock
cycle number? I suspect the later. This means that nanotime results
are only useful for comparing algorithms on the same hardware. If you
want to benchmark hardware you would have to use System.
currentTimeMillis();

The System javadoc says:

"nanoTime()
Returns the current value of the most precise available
system timer, in nanoseconds."

not clock ticks, or anything else system dependent. Of course, the
actual resolution is system-dependent, but should always be at least as
good as currentTimeMillis.

Patricia