Feature/uberenv env #481
Feature/uberenv env #481
Conversation
|
LGTM |
|
LGTM |
| @@ -108,7 +108,7 @@ then | |||
| $cmake_exe \ | |||
| -C ${hostconfig_path} \ | |||
| ${project_dir} | |||
| if ! $cmake_exe --build . -j; then | |||
| if ! $cmake_exe --build . -j 12; then | |||
There was a problem hiding this comment.
I am not sure I understand this. Can you elaborate? Why "12"?
There was a problem hiding this comment.
First the main drawback: 12 is a value "optimized" for quartz.
"-j" maximize the number of threads to use. However, on quartz, we share a node for all builds. Throwing so many threads was counter productive, and could even have lead to shared memory issues. By reducing the maximum number of threads, I got the CI on quartz to run faster, and didn’t have to increase the allocation time.
There was a problem hiding this comment.
Quartz nodes have 2 sockets of 18 cores. Each cores supports 2 hyperthreads, and the 18 cores are organized by groups of 6 (sort of). Hence the 12 value. However, actually pining those threads to cores is again not optimal (per my tests). So I leave the thread orchestration to the OS.
|
LGTM |
|
Hey @adrienbernede - is this something we should clean up and get merged? |
|
@davidbeckingsale I used Umpire as a pilot project to test using Uberenv with spack environment. Also, you can see this branch has only a few changes outside of the uberenv.py script. This script would now be provided by submodule, so updating this branch would mean basically emptying it. I will close it, and we could recreate one from the appropriate branch in Uberenv when we are ready to dedicate some time to it. |
|
Thanks for the explanation! |
This PR is demonstration of how Uberenv can use spack environments.
This changes nothing to Umpire workflow, the only changes are in Uberenv itself, and in spack-configs which is now a submodule.