Fork me on GitHub
#clojure-dev
<
2018-12-05
>
andy.fingerhut07:12:30

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

jumar10:12:27

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.

alexmiller13:12:30

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

👍 1
gfredericks00:12:26

yeah, pluggability would solve this problem and also give reproducibility

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.

alexmiller21:12:38

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

👍 1