Homebrew on Mac M1/M2 systems computes misleading here.maxTaskPar values
#24655
Comments
|
This is a nit, but I don't think Is there a reason why we shouldn't use the bundled |
That's a great point of clarification. Still, I'm concerned about our using all 10 cores (in the sense that it seems certain to result in a load imbalance). I.e., I think the hwloc-oriented behavior is preferable if we could duplicate that in a homebrew install.
That was my instinct as well. Elliot's main reaction (where I should've captured both here) was that we don't have any testing of fifo+bundled hwloc, so he was nervous about the notion of shipping such a configuration as the 2.0 release this week (say). I filed this issue independently of the 2.0 release, though, and we could look into that going forward (or look more into enabling qthreads). The one other reason to consider not doing this is that the homebrew maintainers like us to use external packages rather than bundled ones (not surprising since they're in the package management and interdependence business). I think it was both of these things that motivated Elliot to make the attempt in the third/final bullet of the OP. |
|
Most programs that I use and algorithms that are written by people I know assume that all cores are the same speed. I share Brad's caution at having a load imbalance. |
|
Merging #25145 should resolve this issue, which allows homebrew to build with hwloc. This means a homebrew install will report only the performance cores for The above PR modifies our in tree version of the chapel formula and should propagate to the official homebrew formula during our normal release procedures for 2.1 |
This PR patches some of our build scripts to work with `CHPL_HWLOC=system`. By default, we will still continue to default to `CHPL_HWLOC=bundled` with qthreads, but users can opt in to using a system install by explicitly setting `CHPL_HWLOC=system` This is a step in the right direction to allow us to use the preferred Chapel configuration for Macs in homebrew. Testing: - [x] `start_test test/release/examples` with `CHPL_HWLOC=system` on Mac Notes: - Partially unblocks #24931 and #24655 - Used #23409 as a starting point [Reviewed by @jhh67]
…#25158) This PR patches some of our build configuration scripts to be able to use `CHPL_TARGET_JEMALLOC=system`. This allows us to use our preferred configuration for performance (`CHPL_MEM=jemalloc`) in situations where we cannot build the bundled jemalloc (i.e. for packaging) When using a system jemalloc 5.x, we have to turn off chunk hooks (jemalloc 5.x does not support it) Testing: - [x] `start_test test/release/examples` with `CHPL_MEM=jemalloc` and `CHPL_TARGET_JEMALLOC` on Mac Notes: - Builds on top of #25145 - Fully unblocks #24931 and #24655, and enables homebrew to use the preferred config (#25148) - Uses diffs from #23409 [Reviewed by @jhh67]
Switches the homebrew formula in the chapel tree to use a system install of hwloc, which allows chapel to use qthreads. This results in better performance for users. This also uses a system install of jemalloc, which also increases performance. - [x] Tested locally by install chapel from the homebrew formula and running `chpl examples/hello.chpl && ./hello` To be merged after #25145 and #25158 Resolves #24655 Resolves #24931 [Reviewed by @stonea]
While testing
writeln(here.maxTaskPar);on my M1 Mac using homebrew, I was surprised to see it report10as the result rather than8. I do see8when using a compiler built from source.My understanding is that this is because:
hwlocsupport, so we don't distinguish between them as we do whenhwlocis enabledAnd for additional context:
hwlocdefaults tononewhen usingCHPL_TASKS=fifofifoby default is given here: Homebrew formula: use cstdlib and fifo tasks #23415hwlocin the homebrew environment in Fix support for using a system hwloc and jemalloc #23409The text was updated successfully, but these errors were encountered: