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 <brent.mill...@gmail.com>
wrote:
> 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 100000000]
> (vreset! v @v))))
>
> (print "AtomicLong: ")
> (time
> (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
> (dotimes [x 100000000]
> (.set v (.get v)))))
>
> (print "AtomicReference: ")
> (time
> (let [v (java.util.concurrent.atomic.AtomicReference. {})]
> (dotimes [x 100000000]
> (.set v (.get v)))))
>
> (print "atom: ")
> (time
> (let [v (atom 1)]
> (dotimes [x 100000000]
> (reset! v @v)))))
>
>
> [bmillare@sakura ~]$ java -server -cp
> .m2/repository/org/clojure/clojure/1.7.0-alpha5/clojure-1.7.0-alpha5.jar
> clojure.main timereference.clj
> Java: 1.7.0_75
> 1.7.0-alpha5
> volatile: "Elapsed time: 793.525092 msecs"
> AtomicLong: "Elapsed time: 606.658899 msecs"
> AtomicReference: "Elapsed time: 606.253989 msecs"
> atom: "Elapsed time: 881.198546 msecs"
> volatile: "Elapsed time: 787.714655 msecs"
> AtomicLong: "Elapsed time: 603.810759 msecs"
> AtomicReference: "Elapsed time: 603.811366 msecs"
> atom: "Elapsed time: 1417.625552 msecs"
> volatile: "Elapsed time: 794.154652 msecs"
> AtomicLong: "Elapsed time: 603.718131 msecs"
> AtomicReference: "Elapsed time: 603.723479 msecs"
> atom: "Elapsed time: 866.220579 msecs"
> volatile: "Elapsed time: 787.459397 msecs"
> AtomicLong: "Elapsed time: 603.735881 msecs"
> AtomicReference: "Elapsed time: 603.720108 msecs"
> atom: "Elapsed time: 866.208679 msecs"
> volatile: "Elapsed time: 787.455661 msecs"
> AtomicLong: "Elapsed time: 603.720906 msecs"
> AtomicReference: "Elapsed time: 603.735316 msecs"
> atom: "Elapsed time: 866.226066 msecs"
> volatile: "Elapsed time: 787.455482 msecs"
> AtomicLong: "Elapsed time: 603.720222 msecs"
> AtomicReference: "Elapsed time: 603.718667 msecs"
> atom: "Elapsed time: 866.205402 msecs"
> volatile: "Elapsed time: 789.429405 msecs"
> AtomicLong: "Elapsed time: 603.71242 msecs"
> AtomicReference: "Elapsed time: 603.717922 msecs"
> atom: "Elapsed time: 866.212896 msecs"
> volatile: "Elapsed time: 787.461736 msecs"
> AtomicLong: "Elapsed time: 603.728396 msecs"
> AtomicReference: "Elapsed time: 603.727234 msecs"
> atom: "Elapsed time: 866.203579 msecs"
> volatile: "Elapsed time: 787.462185 msecs"
> AtomicLong: "Elapsed time: 603.721207 msecs"
> AtomicReference: "Elapsed time: 603.716769 msecs"
> atom: "Elapsed time: 866.207913 msecs"
> volatile: "Elapsed time: 787.468805 msecs"
> AtomicLong: "Elapsed time: 603.721715 msecs"
> AtomicReference: "Elapsed time: 603.73172 msecs"
> atom: "Elapsed time: 866.210223 msecs"
>
>
> On Wednesday, March 11, 2015 at 11:57:50 AM UTC-4, tbc++ wrote:
>>
>> 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
>>
>> Timothy Baldridge
>>
>> On Wed, Mar 11, 2015 at 9:38 AM, Brent Millare <brent....@gmail.com>
>> wrote:
>>
>>> Doing some simple microbenchmarks, I found something unexpected:
>>>
>>> (time
>>> (let [v (volatile! 1)]
>>> (dotimes [x 100000000]
>>> (vreset! v @v))))
>>> "Elapsed time: 1016.992146 msecs"
>>>
>>> (time
>>> (let [v (java.util.concurrent.atomic.AtomicLong. 1)]
>>> (dotimes [x 100000000]
>>> (.set v (.get v)))))
>>> "Elapsed time: 672.869727 msecs"
>>>
>>> (time
>>> (let [v (java.util.concurrent.atomic.AtomicReference. {})]
>>> (dotimes [x 100000000]
>>> (.set v (.get v)))))
>>> "Elapsed time: 678.143133 msecs"
>>>
>>> (time
>>> (let [v (atom 1)]
>>> (dotimes [x 100000000]
>>> (reset! v @v))))
>>> "Elapsed time: 1100.689493 msecs"
>>>
>>> I expected volatile's to be faster. Maybe I'm not understanding the
>>> correct use case for volatiles but java.util.concurrent.atomic.Atomic*
>>> seems to be clearly the most performant. Given the downsides of using
>>> volatiles, is their existence justified when safer and faster alternatives
>>> exist?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
> --
> 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/d/optout.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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/d/optout.
