-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hpx: Invalid default variant #44194
Comments
HPX itself actually already defaults to not setting a max CPU count and uses dynamic bitsets instead for CPU masks (that's what the max count is primarily for). The default in the spack package doesn't reflect the HPX default. From previous testing performance was not affected by using dynamic bitsets so changing the default in the spack package would probably make sense. @hkaiser do any of the new schedulers care more about using static or dynamic bitsets? spack/var/spack/repos/builtin/packages/hpx/package.py Lines 61 to 66 in e9149cf
none is a better way to represent it in the spack package?
|
I think currently HPX still uses a maximum of 64 cores as the default internal value (if nothing else was specified). However @msimberg is right that we could (and should) remove this restriction. I will prepare a PR to be integrated with the upcoming HPX V1.10.0 release. |
The max_cpu_count variant for hpx is set to 64 by default. If that value doesn't match the actual number of cpus this can result in runtime failures like:
Does the correct cpu count need to be determined at install time (making binary relocation ungeneralizable for hpx), or is there a flag that can be added at build or runtime to force hpx to allow a sub-optimal cpu count? Alternatively, is there a way to determine the correct value from inside the spack package and use that for configuration?
@albestro @hkaiser @msimberg @teonnik
The text was updated successfully, but these errors were encountered: