Fork me on GitHub

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:


should I open a jira for this?


solve the thing generically


@ghadi: that would be very useful

Alex Miller (Clojure team)01:06:48

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

Alex Miller (Clojure team)02:06:20

that’s all I was asking - what is the use case where it matters? generally those are given more weight

Alex Miller (Clojure team)02:06:00

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).

Alex Miller (Clojure team)12:06:02

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.


But well... it's just me playing guessing games 🙂


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

Alex Miller (Clojure team)19:06:30

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.


but yeah 42 + N was a bit too much, that said there could be some better inference for a decent default (arguably)