On Thu, 1 Jul 2010 23:39:16 -0400 Aaron Cohen <aa...@assonance.org> wrote:
> > If nothing else adding code to measure the empty loop and punting if > > the difference between that and the code loop is statistically > > insignificant would seem like a good idea. > It's actually notoriously hard to time the "empty loop" on the JVM. Once > you've iterated a few thousand times, the JIT will kick in and recognize the > loop does no work (or possibly even find a closed form solution for the loop > if there are simple math ops within it) and remove it entirely. If it tosses out your empty loop, then you're back where you started - timing the loop as well as the operation. If it finds the closed form solution for the real loop - that would explain the results I'm seeing. > Cliff Click devotes entire talks to benchmarking in Java, how hard it is to > do correctly, and the common pitfalls: > http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf ()#*$Q#% PPT. But I think some of the ideas can be incorporated.... Thanks, <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
