Someone asked in Discord if there is a way to ask the CE runtime how many CPUs/compute threads it has access to, so that they can set parallelism factors appropriately. It's available in IOApp as computeWorkerThreadCount but this is specific to IOApp and therefore not easily usable from all the places in c.e.std that could benefit from it.
Once it's added to Spawn, new methods or overrides should be added setting default parallelism factors accordingly. For example, in addition to Random.scalaUtilRandomN, there should be a variant that sets N to the computeWorkerThreadCount.
There was some discussion of this in Discord, which I will attempt to summarize:
- Daniel originally suggested it as
concurrencyFactorHint: Option[Int] (or parallelismFactorHint: Option[Int] in the interest of consistent terminology).
- Arman suggested avoiding the
Option box by defaulting to 0, to which Daniel "didn't totally object," because "technically anything ≤ 0 is semantically invalid anyway" and "if we go with 0 as the default then the fallback could be to tap the runtime anyway"
- There was also some discussion about whether this should be
F[Int] to reflect the reality that the number can change in some circumstances, but that opens up quite a rabbit hole, so it may not be worth it? If F[Int] is used, should there be some kind of notification protocol to let data structures optimized for a given value rebalance themselves if the value changes?
Someone asked in Discord if there is a way to ask the CE runtime how many CPUs/compute threads it has access to, so that they can set parallelism factors appropriately. It's available in
IOAppascomputeWorkerThreadCountbut this is specific toIOAppand therefore not easily usable from all the places inc.e.stdthat could benefit from it.Once it's added to
Spawn, new methods or overrides should be added setting default parallelism factors accordingly. For example, in addition toRandom.scalaUtilRandomN, there should be a variant that setsNto thecomputeWorkerThreadCount.There was some discussion of this in Discord, which I will attempt to summarize:
concurrencyFactorHint: Option[Int](orparallelismFactorHint: Option[Int]in the interest of consistent terminology).Optionbox by defaulting to 0, to which Daniel "didn't totally object," because "technically anything ≤ 0 is semantically invalid anyway" and "if we go with 0 as the default then the fallback could be to tap the runtime anyway"F[Int]to reflect the reality that the number can change in some circumstances, but that opens up quite a rabbit hole, so it may not be worth it? IfF[Int]is used, should there be some kind of notification protocol to let data structures optimized for a given value rebalance themselves if the value changes?