[ANN] core.async 0.2.382

[Alex Miller]

core.async 0.2.382 is now available.

Try it via:  [org.clojure/core.async "0.2.382"]

0.2.382 includes the following changes:

- Change default dispatch thread pool max size to 8.

- Add Java system property clojure.core.async.pool-size to override the dispatch thread pool max size

- ASYNC-152 - disable t.a.jvm's warn-on-reflection pass

[Fluid Dynamics]

On Monday, June 13, 2016 at 4:14:25 PM UTC-4, Alex Miller wrote:

core.async 0.2.382 is now available.

Try it via:  [org.clojure/core.async "0.2.382"]

0.2.382 includes the following changes:

- Change default dispatch thread pool max size to 8.

- Add Java system property clojure.core.async.pool-size to override the dispatch thread pool max size

Why 8, rather than, say, (.availableProcessors (Runtime/getRuntime))?

[Daniel Compton]

Bumping this too. What was the context for this change? I don’t see any JIRA tickets linked in the commits with a rationale for why 8 was picked as the thread pool size. This has the potential for breaking or reducing efficiency for apps that were relying on the 42 + 2 * cores behaviour. I’m happy that this is now configurable, but puzzled as to why the default wasn’t kept as 42 + 2 * cores? 

Also, because this needs to be passed as a java property, if we want our applications to be able to handle differing core counts (e.g. running on heterogenous servers) it seems like we will need to write a bash script to calculate our threadpool size before starting up.

Perhaps I’m missing something really obvious here, if so, please let me know :)

Tim Ewald, can you help with this?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

—

Daniel

[Daniel Compton]

I knew I must be missing something. You can also set the core.async threadpool size with

(System/setProperty "clojure.core.async.pool-size" "42")

as long as that runs before any core.async code tries to use the threadpool. Some context on why the change was made to 8 would be good, but it is easy to set this value yourself.

--

—

Daniel

[Ning Sun]

I guess this change is to encourage user to configure their own pool
size based on their use case, instead of completely relying on the default.

On 06/23/2016 11:33 AM, Daniel Compton wrote:
> I knew I must be missing something. You can also set the core.async
> threadpool size with
>
> (System/setProperty "clojure.core.async.pool-size" "42")
>
> as long as that runs before any core.async code tries to use the
> threadpool. Some context on why the change was made to 8 would be good,
> but it is easy to set this value yourself.
>
> On Thu, Jun 23, 2016 at 9:13 AM Daniel Compton

> <daniel.com...@gmail.com <mailto:daniel.com...@gmail.com>>

> wrote:
>
> Bumping this too. What was the context for this change? I don’t see
> any JIRA tickets linked in the commits

> <https://github.com/clojure/core.async/compare/07e70e47a0d2f3f6b606fe2ed3a993b83cf2c29f...503b597a46a49f7d86cfb9afbe1d92798de8e2fa> with

> <mailto:clo...@googlegroups.com>

> Note that posts from new members are moderated - please be
> patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com

> <mailto:clojure%2Bunsu...@googlegroups.com>

> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the
> Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to clojure+u...@googlegroups.com

> <mailto:clojure+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> —
> Daniel
>
> --
> —
> Daniel
>

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com

> <mailto:clojure+u...@googlegroups.com>.

[Alex Miller]

First, note that this is a *max* pool size. There is no "right" number. 42+2n was "a lot" (and sometimes too many). 8 is "less" and a reasonable number for 2-8 core machines common in servers. More important is that it's now configurable to a number that's good for you.

On Wednesday, June 22, 2016 at 4:14:15 PM UTC-5, Daniel Compton wrote:

Bumping this too. What was the context for this change? I don’t see any JIRA tickets linked in the commits with a rationale for why 8 was picked as the thread pool size. This has the potential for breaking or reducing efficiency for apps that were relying on the 42 + 2 * cores behaviour. I’m happy that this is now configurable, but puzzled as to why the default wasn’t kept as 42 + 2 * cores? 

Also, because this needs to be passed as a java property, if we want our applications to be able to handle differing core counts (e.g. running on heterogenous servers) it seems like we will need to write a bash script to calculate our threadpool size before starting up.

Perhaps I’m missing something really obvious here, if so, please let me know :)

Tim Ewald, can you help with this?

On Tue, Jun 14, 2016 at 9:10 AM Fluid Dynamics <a209...@trbvm.com> wrote:

On Monday, June 13, 2016 at 4:14:25 PM UTC-4, Alex Miller wrote:

core.async 0.2.382 is now available.

Try it via:  [org.clojure/core.async "0.2.382"]

0.2.382 includes the following changes:

- Change default dispatch thread pool max size to 8.

- Add Java system property clojure.core.async.pool-size to override the dispatch thread pool max size

Why 8, rather than, say, (.availableProcessors (Runtime/getRuntime))?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

—

Daniel

[Alan Moore]

Shouldn't the default be a value related to the number of cores like the original too large default was?

Maybe not exactly (.availableProcessors (Runtime/getRuntime)), as suggested by Fluid Dynamics, but something similar? In just about every case where the # cores != 8 you will be under/over provisioning. Is there a reason a constant was used such as to provide consistent behavior such as test output from run to run?

Just curious what the thinking was behind choosing a constant over a per-core value.

Alan