This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-22
Channels
- # beginners (8)
- # boot (41)
- # cider (1)
- # cljsrn (2)
- # clojure (91)
- # clojure-dev (34)
- # clojure-gamedev (3)
- # clojure-germany (6)
- # clojure-greece (324)
- # clojure-japan (2)
- # clojure-miami (4)
- # clojure-nl (6)
- # clojure-quebec (3)
- # clojure-russia (26)
- # clojure-spec (50)
- # clojure-uk (19)
- # clojurescript (147)
- # core-async (5)
- # css (2)
- # cursive (15)
- # datascript (7)
- # datomic (6)
- # hoplon (1)
- # jobs (4)
- # lein-figwheel (17)
- # off-topic (4)
- # om (52)
- # om-next (10)
- # onyx (1)
- # planck (19)
- # proton (1)
- # re-frame (81)
- # reagent (61)
- # spacemacs (1)
- # specter (46)
- # spirituality-ethics (7)
- # untangled (7)
- # yada (17)
Why did the core.async threadpool go from 42 to 8, and why isn't it using the core count?
For context, you’re talking about https://github.com/clojure/core.async/commit/a690c4f3b7bf9ae9e7bdc899c030955d5933042d right?
It does seem like the kind of thing that should be noted a bit brighter in the changelog
I think the far more important thing is that it's now configurable
It was noted in the announcement email and the read me and is at the top of the apidocs (how to configure) - in what "brighter" way could it have been mentioned?
sadly this only allows to have 1 setup for a whole jvm instance (you can't have different pools for different contexts)
also if a piece of code changes that limit before you do, no way to change anything (since it's trapped in a defonce+delay)
I think what ztellman did with Manifold is a good example of a configurable execution policy: https://github.com/ztellman/manifold/blob/master/docs/execution.md
That's what I modeled my changes after in the jira issue mentionned (I am not saying the code is acceptable, but the approach/idea seems more flexible)
Regarding invokedynamic: While thankfully Rich isn't driven by features, it may be time to re-evaluate invokedynamic, as the implementation has stabilized greatly. Regarding JRuby's woes with indy: I'm less persuaded by the fact that they had legit troubles with it because Ruby's dynamism is on another level than Clojure's (e.g. method lookup chain). When I first started looking at indy, I initially thought that opportunities for Clojure would include higher peak performance (and there are still improvements in that area), my current thoughts center surprisingly around improving startup time. http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-August/005890.html (required reading from JVM architect John Rose.) > ... we expect the overhead of a method handle to be more like the overhead of a closure and less like the overhead of an inner class. This means that you will win if you "compress" your call sites using indy instead of open-coding them with many bytecodes. The warm-up will process the compact form, leading to less net data motion for loading, while the hot form of the code will be indistinguishable from the open-coded version. - Faster/lazier init of clojure's "constant pool" (aka the <clinit> method) - Get rid of "bytecode boilerplate" for keyword or protocol invokes, vector and map creation
A practical example of "open-coded bytecode" is a map expression:
(fn [foo] {:a foo :b 42})
The bytecode creates an array, then loads :a
onto the stack, puts it into the array, then does the same with foo
:b
42
, then passes the array to RT/map
A "compressed" callsite would just load all the elements onto the stack and call an indy instruction that is bootstrapped with a method handle that encapsulates rolling things into an array and calling a map constructor
Interesting that indy’s benefits have changed in that way. Thanks @ghadi !
@ghadi: thanks for that info... I've been investigating (very early still) a lazy loading approach similar to what the fastload branch achieved, but using invokedynamic and constant call sites
it's really mostly for my own sake, learning more about invoke dynamic (and the clojure compiler obvs), but started to wonder if indy was at all under consideration
@alexmiller: Maybe just putting a Breaking: in the changelog?
@danielcompton: I agree the change is important, but we should reserve “breaking” for places where documented semantics are broken. Is there a documented semantic that changed?
Note that the setting is the max pool size so it should have no effect on apps that never have more than 8 concurrent go blocks
Note also that this change does not preclude adding more pool control in the future
Aka no is temporary, yes is forever
@mpenet Re the thread function, that doesn't use a pool at all and is just a convenience. You can spin up your own threads and do async things however you like.
So is far less important than the go thread pool imo
Perhaps Important then? Lowering the thread count in the thread pool seems like it could break/diminish effectiveness of peoples code where they were relying on there being more threads in the pool. https://groups.google.com/d/msg/clojure/EDkrj-45vb4/VLNONJW5AQAJ
@alexmiller: sure, thread
issue is not very important. It's easy enough copy paste the code and fix the issue by ourself. Then again I would consider using an unbounded thread pool kinda unusable personnally. It's ok for toy stuff, but not usable otherwise. But I couldn't care less as long as chan ops and go blocks get more knobs first
8 just seems like a really weird number to pick out of a hat, not that 42 wasn't weird, but I would expect numbers to become more meaningful over time, or become self tuning, 42 -> 8 just seems like trading one arbitrary number for another, my guess is it isn't arbitrary, and the reason 8 is more meaningful than 42 is something I don't know, so for my own edification it would be nice to know
@hiredman: also, it was 42 + core count * 2 which is somewhat self tuning, whereas 8 is fixed
There is no right number. The important part is that it's configurable.