Re: Timing, JIT, Heisen-code

2009-10-29 Thread Matt Brown
Hello all. Thanks everyone for the comments. This was the kind of info I was looking for. I'll play around with this some more when I get a chance. (Too many grants due / conferences in October.) cheers Matt On Oct 1, 10:08 am, Jonathan Smith wrote: > On Sep 30, 1:18 pm, Matt Brown wrote: >

Re: Timing, JIT, Heisen-code

2009-10-01 Thread Jonathan Smith
On Sep 30, 1:18 pm, Matt Brown wrote: > Hi. > > Thanks all, for your comments. > > > You need to use a bigger number than 1000 for these results to be > > meaningful. > > Out of curiousity, why is this? > Does the JIT do something different after 1000 iterations? > Or is the concern simply tha

Re: Timing, JIT, Heisen-code

2009-10-01 Thread Fredrik Ohrstrom
Oh, and by the way: the expression (+ 1 2 3) is indeed a constant. Be very wary of tests that verify the execution speed of constants since it is definitely the goal of the JVM developers to make the JVM compile these into a single constant mov in the machine code! Of course such code is so fast

Re: Timing, JIT, Heisen-code

2009-10-01 Thread Fredrik Ohrstrom
You are trusting nanoTime to actually return values that are useful! They might be completely useless for your timing purposes. :-) It all depends on the hardware you are running. Read the spec: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime() The reason for this is that

Re: Timing, JIT, Heisen-code

2009-09-30 Thread Christophe Grand
Hi, On Wed, Sep 30, 2009 at 7:18 PM, Matt Brown wrote: > Using a million iterations, I got: > (myavgtime (+ 1 2 3) 1e6 mytime1) -> 0.00027 - 0.00029 msec (over a > dozen repeats) > (myavgtime (+ 1 2 3) 1e6 mytime2) -> 0.00068 msec (single run, > printing 10^6 lines takes a long time, I was too i

Re: Timing, JIT, Heisen-code

2009-09-30 Thread Matt Brown
Hi. Thanks all, for your comments. > You need to use a bigger number than 1000 for these results to be meaningful. Out of curiousity, why is this? Does the JIT do something different after 1000 iterations? Or is the concern simply that the variance of the mean estimate is too high with 1000 vs.

Re: Timing, JIT, Heisen-code

2009-09-30 Thread Jonathan Smith
You need to use a bigger number than 1000 for these results to be meaningful. FWIW, I've run both on my Toshiba dual core laptop with ubuntu, and they return approximately the same values. (and there is some JIT trickery going on, as I got: user=> (myavgtime (+ 1 2 3) 1000 mytime1) (myavgtime (+

Re: Timing, JIT, Heisen-code

2009-09-30 Thread Cliff Wells
On Tue, 2009-09-29 at 22:54 -0700, Meikel Brandmeyer wrote: > Hi, > > On Sep 30, 12:19 am, Cliff Wells wrote: > > > In short, you've taken something that was originally CPU-bound and made it > > I/O-bound. > > I don't think so. The measured times do not include the println. The > loop with th

Re: Timing, JIT, Heisen-code

2009-09-29 Thread Meikel Brandmeyer
Hi, On Sep 30, 12:19 am, Cliff Wells wrote: > In short, you've taken something that was originally CPU-bound and made it > I/O-bound. I don't think so. The measured times do not include the println. The loop with the print will itself run longer, but the average time printed does not count th

Re: Timing, JIT, Heisen-code

2009-09-29 Thread Cliff Wells
On Tue, 2009-09-29 at 09:08 -0700, Matt wrote: > So, using mytime2 with the myavgtime macro gives average execution > times for the expression (+ 1 2 3) of 2 to 3 times longer than when > using mytime1. Why is this? Does the JIT optimize differently with all > those println's when using mytime2?

Timing, JIT, Heisen-code

2009-09-29 Thread Matt
Hi. I'm getting a three-fold difference in timing results when I add a seemingly trivial println to observe what's going on. Consider: (defmacro mytime1 "Returns execution time of expr in millisecs" [expr] `(let [time0# (. System nanoTime) exprval# ~expr time1# (/ (double