clojure-dev 2018-12-05 | Slack Archive

Alex, have you been spamming the Google group again? You know I'll have to ban you if you keep doing that ...

Would it make sense to replace Math/random with ThreadLocalRandom (https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadLocalRandom.html) ? Looking at rand-int, rand, rand-nth.

jumar10:12:05

Quick micro-benchmarks in the REPL:

(defn rand [n] (-> (java.util.concurrent.ThreadLocalRandom/current) (.nextDouble n)) )

(crit/quick-bench (rand 10000))
Evaluation count : 20626890 in 6 samples of 3437815 calls.
             Execution time mean : 21.527711 ns
    Execution time std-deviation : 4.719832 ns
   Execution time lower quantile : 17.964367 ns ( 2.5%)
   Execution time upper quantile : 27.755872 ns (97.5%)
                   Overhead used : 10.487063 ns

(crit/quick-bench (clojure.core/rand 10000))
Evaluation count : 7058808 in 6 samples of 1176468 calls.
             Execution time mean : 58.988887 ns
    Execution time std-deviation : 12.328620 ns
   Execution time lower quantile : 51.052229 ns ( 2.5%)
   Execution time upper quantile : 77.901138 ns (97.5%)
                   Overhead used : 10.487063 ns

Of course, that doesn't say that much but it seems to me that ThreadLocalRandom implementation should be generally faster, especially in the multi-threading environments.

Alex Miller (Clojure team)13:12:30

I believe there is a ticket for this actually, or rather to make it pluggable

👍 4

gfredericks00:12:26

yeah, pluggability would solve this problem and also give reproducibility

Alex Miller (Clojure team)14:12:07

https://dev.clojure.org/jira/browse/CLJ-1452

gfredericks20:12:35

BTW I'd be happy to do work on that ticket if it's blocked on userspace attention. At a glance it seemed like it needed kernel processes.

Alex Miller (Clojure team)21:12:38

I wouldn’t bother working on it unless Rich vets it

👍 4

2018-12-05

Channels