Hmm, it seems like if it were JIT related you'd see the same issue with java code, but I get 5ns across the board.
https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote: > > Verified that I receive the same result patterns as you on my machine. > > One other possibility outside of what you have already mentioned would be > something JIT-related. Perhaps there is an optimization that can be > performed if the locking sections of the code are in another function but > otherwise no, but I'm not sure how that dovetails with Clojure' fn > compilation. > > On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote: >> >> Since 1.6 alpha is out, I reran the tests with that -- basically the same >> results. >> >> On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume 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.
