Skip to content

Conversation

@mvhulten
Copy link
Contributor

For components using the CMake build tool; tested with ParFlow.

Four threads appears to be the sweet spot. Walltimes (ParFlow only):

-j 1 -> 164 s
-j 2 -> 100 s
-j 4 -> 64 s
-j 8 -> 50 s

For components using the CMake build tool; tested with ParFlow.

Four threads appears to be the sweet spot.  Walltimes (ParFlow only):

-j 1 -> 164 s
-j 2 -> 100 s
-j 4 ->  64 s
-j 8 ->  50 s
@mvhulten mvhulten requested review from kvrigor and s-poll August 15, 2025 11:36
@mvhulten
Copy link
Contributor Author

I don't know how to do this for ParFlow alone, but it should not break building of any other component as it is CMake native.

Maybe CI is also faster now. Can this be checked?

Copy link
Member

@kvrigor kvrigor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a good idea to hardcode --parallel 4 as it would pose a problem for coupled builds (see #62). Instead what I'd suggest is to parameterize the # of build threads, e.g.:

# default.env should provide a default setting for TSMP2_PARALLEL_JOBS.
# Either default=1 or a machine-specific default value.
export TSMP2_PARALLEL_JOBS=4

# Should be aware of TSMP2_PARALLEL_JOBS setting
./build_tsmp2.sh ...

This way you can still enable parallel builds while keeping the default build behavior to a known working state (i.e. -j1).

@mvhulten
Copy link
Contributor Author

Firstly, I don't see what TSMP2_PARALLEL_JOBS does (assuming we're not going to write somewhere later --parallel $TSMP2_PARALLEL_JOBS, because then I'm missing the point).

Then, I suppose it is still not good enough, because your amended solution would mean that we have to test anyway if "-j 4" works on JSC machines. This is where I want to use it, at least sometimes.

I suppose, by default it must everywhere be "-j 1", and we could introduce build_tsmp2.sh --jobs and then add to the build command --parallel $jobs.

This reverts commit 7c7b303, because it
would pose a problem for coupled builds.
@mvhulten
Copy link
Contributor Author

  • It's important here to squash all commits
  • There is the -j 8 of ICON to consider, but I don't think it matters (just in that the --help is lying)

@kvrigor
Copy link
Member

kvrigor commented Aug 25, 2025

assuming we're not going to write somewhere later --parallel $TSMP2_PARALLEL_JOBS

I was thinking to use TSMP2_PARALLEL_JOBS to parallelize builds within Build*.cmake scripts. Currently each component model uses a hardcoded -j setting. These hardcoded settings can be replaced by reading from the TSMP2_PARALLEL_JOBS env var.

Then, I suppose it is still not good enough, because your amended solution would mean that we have to test anyway if "-j 4" works on JSC machines. This is where I want to use it, at least sometimes.

It makes more sense to set the optimal TSMP2_PARALLEL_JOBS per machine thru environment files. If we do it this way, the default env file should set a conservative setting of TSMP2_PARALLEL_JOBS=1.

mkdir -p "${cmake_install_dir}"

if [ -v max_jobs ]; then
export CMAKE_BUILD_PARALLEL_LEVEL=${max_jobs}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMAKE_BUILD_PARALLEL_LEVEL can trigger intercomponent parallel builds which we don't want (see #62)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants