Good detective work, Michal. So the extra time for the slower version was because a Var was always being accessed in the generated byte code, even if the source code was only explicitly accessing the Var in a branch that was never executed?
Thanks, Andy On Sun, Nov 3, 2013 at 9:30 AM, Michał Marczyk <michal.marc...@gmail.com>wrote: > You have a typo in foo -- monitor-exit's argument is 0 (zero) rather > than o (the sentinel object). > > Besides that, in foo both monitor-enter and monitor-exit get their > arguments from a Var. Rewriting to use locking, which first puts the > object whose monitor will be used in a local (that is, (let [lockee o] > ...), where ... performs the locking using the newly introduced > local), gives timings identical to those of bar and baz: > > (defn foo' [x] > (if (> x 0) > (inc x) > (let [res (locking o (dec x))] res))) > > So this is one reason not to use monitor-enter and monitor-exit > directly. Another reason is that locking guarantees that the monitor > will be released (by using try / finally, and of course by preventing > situations where the matching monitor-enter & monitor-exit operate on > different objects). > > In fact, both monitor-enter and monitor-exit carry docstrings which > explicitly say that they should not be used in user code and point to > locking as the user-facing equivalent to Java's synchronized. > > Cheers, > Michał > > > On 1 November 2013 19:34, Michael Blume <blume.m...@gmail.com> wrote: > > https://github.com/MichaelBlume/perf-test > > > > (ns perf-test > > (:use (criterium core)) > > (:gen-class)) > > > > (def o (Object.)) > > > > (defn foo [x] > > (if (> x 0) > > (inc x) > > (do > > (monitor-enter o) > > (let [res (dec x)] > > (monitor-exit 0) > > res)))) > > > > (defn bar [x] > > (if (> x 0) > > (inc x) > > (dec x))) > > > > (defn locking-part [x l] > > (monitor-enter l) > > (let [res (dec x)] > > (monitor-exit l) > > res)) > > > > (defn baz [x] > > (if (> x 0) > > (inc x) > > (locking-part x o))) > > > > (defn -main [] > > (println "benching foo") > > (bench (foo 5) :verbose) > > (println "benching bar") > > (bench (bar 5) :verbose) > > (println "benching baz") > > (bench (baz 5) :verbose) > > (println "done benching")) > > > > > > > > I'm only ever calling these functions with positive values, so the > > monitor-enter branch should never be entered. Nevertheless, the > performance > > of foo is much worse than bar or baz. > > > > The best guess I've got is that the fact that lock-taking is involved > > somehow changes how the function is compiled, somehow making the function > > slower. If the practical upshot is that I shouldn't write functions that > > only sometimes lock -- that the locking part of a function should always > be > > its own function -- then I can do that, but I'm curious why. > > > > $ lein uberjar > > Compiling perf-test > > Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar > > Created > /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar > > $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar > > benching foo > > WARNING: Final GC required 1.5974571326266802 % of runtime > > x86_64 Mac OS X 10.8.3 4 cpu(s) > > Java HotSpot(TM) 64-Bit Server VM 24.0-b28 > > Runtime arguments: > > Evaluation count : 391582560 in 60 samples of 6526376 calls. > > Execution time sample mean : 167.426696 ns > > Execution time mean : 167.459429 ns > > Execution time sample std-deviation : 4.079466 ns > > Execution time std-deviation : 4.097819 ns > > Execution time lower quantile : 160.742869 ns ( 2.5%) > > Execution time upper quantile : 175.453376 ns (97.5%) > > Overhead used : 1.634996 ns > > > > Found 2 outliers in 60 samples (3.3333 %) > > low-severe 2 (3.3333 %) > > Variance from outliers : 12.5602 % Variance is moderately inflated by > > outliers > > benching bar > > x86_64 Mac OS X 10.8.3 4 cpu(s) > > Java HotSpot(TM) 64-Bit Server VM 24.0-b28 > > Runtime arguments: > > Evaluation count : 2174037300 in 60 samples of 36233955 calls. > > Execution time sample mean : 26.068923 ns > > Execution time mean : 26.066422 ns > > Execution time sample std-deviation : 0.887937 ns > > Execution time std-deviation : 0.916861 ns > > Execution time lower quantile : 23.996763 ns ( 2.5%) > > Execution time upper quantile : 27.911936 ns (97.5%) > > Overhead used : 1.634996 ns > > > > Found 3 outliers in 60 samples (5.0000 %) > > low-severe 1 (1.6667 %) > > low-mild 1 (1.6667 %) > > high-mild 1 (1.6667 %) > > Variance from outliers : 22.1874 % Variance is moderately inflated by > > outliers > > benching baz > > x86_64 Mac OS X 10.8.3 4 cpu(s) > > Java HotSpot(TM) 64-Bit Server VM 24.0-b28 > > Runtime arguments: > > Evaluation count : 2270676660 in 60 samples of 37844611 calls. > > Execution time sample mean : 25.834142 ns > > Execution time mean : 25.837429 ns > > Execution time sample std-deviation : 0.718382 ns > > Execution time std-deviation : 0.729431 ns > > Execution time lower quantile : 24.837925 ns ( 2.5%) > > Execution time upper quantile : 27.595781 ns (97.5%) > > Overhead used : 1.634996 ns > > > > Found 4 outliers in 60 samples (6.6667 %) > > low-severe 2 (3.3333 %) > > low-mild 2 (3.3333 %) > > Variance from outliers : 15.7591 % Variance is moderately inflated by > > outliers > > done benching > > > > -- > > -- > > 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 > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
