This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-23
Channels
- # admin-announcements (2)
- # arachne (2)
- # beginners (76)
- # boot (241)
- # cider (14)
- # cljsrn (2)
- # clojars (3)
- # clojure (94)
- # clojure-android (12)
- # clojure-dev (33)
- # clojure-gamedev (1)
- # clojure-greece (3)
- # clojure-india (1)
- # clojure-nl (2)
- # clojure-quebec (3)
- # clojure-russia (21)
- # clojure-spec (38)
- # clojure-uk (72)
- # clojurescript (62)
- # cursive (20)
- # datascript (3)
- # datomic (14)
- # devcards (1)
- # dirac (14)
- # emacs (11)
- # hoplon (7)
- # jobs (2)
- # keechma (1)
- # lein-figwheel (9)
- # leiningen (9)
- # luminus (1)
- # off-topic (6)
- # om (13)
- # onyx (30)
- # planck (181)
- # proton (3)
- # re-frame (6)
- # reagent (6)
- # specter (108)
- # spirituality-ethics (7)
- # untangled (3)
looking at the implementation of constantly
, it seems that it could be a lot more efficient by listing out an implementation for every arity
a quick benchmark shows 3x performance improvement for arity 3: https://gist.github.com/nathanmarz/1dc9ea1ff219ca2f1fa25e7d6f5fbfd1
should I open a jira for this?
@nathanmarz: i welcome work on this http://dev.clojure.org/jira/browse/CLJ-731
@ghadi: that would be very useful
where “3x” = 6 ns vs 18 ns. why is this important?
replacing constantly
with fast-constantly
in Specter shows a 5% performance improvement for some use cases
it's perfectly reasonable for the result of constantly
to be in a hot code path
unless there's some tradeoff I'm not seeing, faster is better
that’s all I was asking - what is the use case where it matters? generally those are given more weight
the tradeoff is of course always having to maintain more code and special cases
@alexmiller: the difference between 8 and 42 + core * 2 is that 42 is relatively self tuning, and (maybe?) a reasonable default. 8 seems like a bad default (too low).
good thing it’s configurable now then!
yes, but the fact is that is now configurable does not explain why now the default value is arbitrary too low (worst than the previous one)...
What I would guess: given an expectation of go blocks being CPU bound and throughput oriented, less threads doing more work would be better, lowering the context switch. That said, core
would be a better default than a fixed 8.
But 8 was chosen instead because core will probably be a different number between dev/prod machines, and could hide some bugs (like those exposed on the ML when 42 -> 8). It's worse than not be self-tunning but at least is predictable.
8 was chosen because it is the number of vertices on a standard bikeshed
And now the assumption is that you’d set the default higher via JVM options on servers that have plenty of cores, just as you’d set any other JVM tuning options.
Do folks think having 44 threads in the pool on a single CPU machine is a good idea?
If your server has 8 CPUs, what would be a reasonable limit? (also assuming there are other thread pools in play outside core.async
and there are also thread
blocks which are not part of the pool) What about a 24 CPU server?
If the answer is "it depends" then no default that Clojure/core choose is ever going to suit everyone (which makes perfect sense — no "one size fits all").
what about server memory footprint?
what about granularity of tasks?
Exactly. "It depends".
@alexmiller: do you know if anybody is working on porting the reader enhancements to tools.reader
? Will do that myself this weekend if not
No one has done that yet so that would be great
@seancorfield: depends on the CPU, nb of CPUs doesn't mean much by itself anymore, it's mostly about number of cores/hw threads per core.