Hi, Deniel.
I made minor change from example (https://clojure.org/reference/refs) and
now Clojure code works at speed 60-80% of pure Java code.
I changed level of lock (refs). In example of clojure org level of refs is
higher and that is why code works slower, i.e [ (ref[ 0 1 2..]) (ref [..])
.. ]
I made [ [(ref 0) (ref 1) ...] [ ref ...] ...] and now it is flying.
Here is the code:
(defn run [nvecs nitems nthreads niters]
(let [vec-refs (vec (map vec (partition nitems (map ref (range (* nvecs
nitems))))))
swap #(let [v1 (rand-int nvecs)
v2 (rand-int nvecs)
i1 (rand-int nitems)
i2 (rand-int nitems)]
(dosync
(let [temp @(nth (vec-refs v1) i1)]
(ref-set (nth (vec-refs v1) i1) @(nth (vec-refs v2) i2))
(ref-set (nth (vec-refs v2) i2) temp))))
report #(do
(println "Distinct:"
(count (distinct (map deref (apply concat
vec-refs))))))]
(dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)))))
(report)))
вторник, 17 октября 2017 г., 0:19:26 UTC+3 пользователь Daniel Compton
написал:
>
> Hi Mike
>
> A few thoughts
>
> * In my experience it is not unusual that idiomatic Clojure could be 10x
> slower than the equivalent Java.
> * Where did you do your timing on the ref calculation? In the Clojure
> version it calculates distinct at the end.
> * How did you do your benchmarking? JVM benchmarking is very tricky, and
> could easily overwhelm all other results.
> * Have you verified that your Java code is correct under all situations?
>
> Overall I think this is a good illustration of a tradeoff that Clojure
> makes against Java. Idiomatic Clojure code is often slower than the Java
> that one might write. However (to my eyes) it is far easier to read,
> understand, and crucially to verify correctness even on the small example
> of swapping numbers. Most of the time, for most systems this is a good
> tradeoff. Ensuring correctness and performance with locks in a larger
> concurrent system becomes even more difficult.
>
> However if performance is critical, and you have the time and skill to
> verify that your locking algorithm is correct, then you can always use
> locks. Either through direct calls to Java interop, or writing your locking
> code in Java and calling that via Java interop.
>
> For more info on this, you can read the conversation between Rich Hickey
> and Cliff Click about STMs vs Locks
> <http://web.archive.org/web/20100405125722/http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.html>
> .
>
> --
> Daniel.
>
> On Mon, Oct 16, 2017 at 7:44 PM Mike <145...@gmail.com <javascript:>>
> wrote:
>
>> https://clojure.org/reference/refs correct link
>>
>>
>> --
>> 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
>> <javascript:>
>> 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 <javascript:>
>> 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 <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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.
