Project Lambda: Java Language Specification draft

[Osvaldo Doederlein]

2010/1/29 Zdenek Tronicek <tronicek at fit.cvut.cz>

> Hi Remi,
>
> System.nanoTime() is not very suitable for performance tests because
> neither Unix nor Windows have resolution of 1ns. The resolution is
> typically 100-1000 times lower.
> So, I changed System.nanoTime() to System.currentTimeMillis(), increased
> the size of the list to 1000000 (million), and looping through get() is
> faster than looping through Iterator. Difference is approx. 7%.
> (On Windows XP, Intel).
>

(IOnly read this reply now.) ~200ns accuracy is certainly better than 1ms;
in my experience, nanoTime() definitely beats currentTimeMillis() when you
are measuring operations in nanosecond scale. Of course it's still critical
to keep the total execution time (of each measurement) much above 1ms,
preferably close to 1s. But the extra accuracy of nanoTime() will never
hurt... especially on OSes with a crappy timer, like Windows Vista (and all
older Windows) that has a ~15ms timer (Windows 7 moves to 1ms, so
currentTimeMillis() will honor 1ms precision). And if you run on an OS
capable of Real-Time scheduling (e.g. Solaris 10's soft-RT sched class), I
expect the nanoTime() API to provide even better real-world accuracy.

A+
Osvaldo


> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Rémi Forax napsal(a):
> > Le 29/01/2010 06:16, Neal Gafter a écrit :
> >> On Thu, Jan 28, 2010 at 4:05 PM, Rémi Forax<forax at univ-mlv.fr>  wrote:
> >>> Le 28/01/2010 20:11, Neal Gafter a écrit :
> >>>> By the way, looping through an ArrayList using indexing happens to be
> >>>> faster than looping through using an iterator because the latter
> >>>> requires two method calls per element, while the former requires only
> >>>> one.  It's not hard to verify this experimentally.
> >>> This not true if the code is hot.
> >> Have you run experiments to back up that assertion?
> >
> > Yes,
> > I had done a similar experiment one week ago when testing method handles.
> > I've updated it this morning to remove method handle things.
> > You can find the two codes and the generated assembler codes is here:
> > http://cr.openjdk.java.net/~forax/assembly-loop/loop-assembly.zip<http://cr.openjdk.java.net/%7Eforax/assembly-loop/loop-assembly.zip>
> >
> > Look for a method named __test__  and takes the second one,
> > the first one is generated before Hotspot decides to inline iterator's
> > methods.
> >
> > The method increment do parsing/toString to avoid to be inlined,
> > __test__ is not inlined too.
> > I've also tried to use the Iterator of a LinkedList during the warm-up
> > to avoid too easy code for a CHA analysis but it doesn't change the
> > generated code.
> >
> > Rémi
> >
> >
>
>
>