This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-05
Channels
- # adventofcode (246)
- # aleph (5)
- # aws (7)
- # beginners (161)
- # boot (3)
- # calva (42)
- # cider (40)
- # clara (10)
- # cljdoc (7)
- # cljs-dev (40)
- # cljsrn (6)
- # clojure (170)
- # clojure-dev (8)
- # clojure-greece (2)
- # clojure-italy (15)
- # clojure-kc (2)
- # clojure-new-zealand (13)
- # clojure-nl (13)
- # clojure-russia (3)
- # clojure-spec (5)
- # clojure-uk (160)
- # clojurescript (72)
- # clojurex (1)
- # cursive (7)
- # data-science (9)
- # datascript (1)
- # datomic (120)
- # devcards (4)
- # emacs (18)
- # figwheel-main (10)
- # fulcro (34)
- # kaocha (3)
- # luminus (1)
- # lumo (6)
- # music (1)
- # nrepl (23)
- # off-topic (2)
- # pedestal (4)
- # re-frame (42)
- # reagent (36)
- # reitit (10)
- # ring-swagger (21)
- # shadow-cljs (124)
- # spacemacs (6)
- # tools-deps (14)
- # unrepl (3)
- # vim (2)
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
.
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.I believe there is a ticket for this actually, or rather to make it pluggable
👍 4
yeah, pluggability would solve this problem and also give reproducibility
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.