Good catch. With criterium, I can detect the small performance improvement.
volatile: Evaluation count : 7550019420 in 60 samples of 125833657 calls.
Execution time mean : 6.345042 ns
Execution time std-deviation : 0.126086 ns
Execution time lower quantile : 6.223058 ns ( 2.5%)
Actaully I think it comes down to the use of the rather generic Deref. I
fired up a repl and ran the following
(let [v (clojure.lang.Volatile. {})]
(dotimes [x ...]
(.reset v (.deref v
I'm seeing very similar times to the one for the AtomicReference.
Timothy
On Wed, Mar 11, 2015 at 11
Doing some simple microbenchmarks, I found something unexpected:
(time
(let [v (volatile! 1)]
(dotimes [x 1]
(vreset! v @v
"Elapsed time: 1016.992146 msecs"
(time
(let [v (java.util.concurrent.atomic.AtomicLong. 1)]
(dotimes [x 1]
(.set v (.get v)
"Elapse
Thanks for the extra analysis!
>
--
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
I took a look at the bytecode of what was generated using no.disassemble
(wrapping parts of the test code into defn's to disassemble it). I saw a
couple of things going on, but I'm not sure exactly what it all means as
I'm not super familiar with when Hotspot does method inlining. Maybe
someon
I find it hard to believe GC would be a factor since there is very little
being generated here. Also, while the outside loop is only 10 iterations of
timings, in the inside loops the code is called for 100 million iterations.
Anyways, running it with criterium didn't change the ranking.
Here is
There's many other factors involved here though, GC, JIT warmup, etc.
That's kindof what criterium helps out with, removing all the variables and
running something until the JIT has warmed up enough (10 iterations
probably isn't enough).
Timothy
On Wed, Mar 11, 2015 at 10:19 AM, Brent Millare
wr
Well not exactly what you said cause I'm lazy, but a little bit more
controlled:
timereference.clj:
(println "Java: "(System/getProperty "java.version"))
(println (clojure-version))
(dotimes [y 10]
(print "volatile: ")
(time
(let [v (volatile! 1)]
(dotimes [x 1]
(vrese
This is interesting, but there could be many things in play here. Try
re-running the tests outside of lein (via compilation to a uberjar and then
running with java -jar) and also use criterium, as it will warn about many
things that coul effect performance .
https://github.com/hugoduncan/criterium
