What happens
-j/--jobs defaults to 1:
-j, --jobs JOBS Allows for JOBS concurrent jobs. (default: 1)
That is easy to remember for ./mfc.sh build, where you are consciously building. It is easy to forget for ./mfc.sh run, which builds as a side effect of running -- and there the default means a full Cray GPU compile proceeds one file at a time:
cmake --build .../staging/gpu-mp-<hash> --target simulation
\_ /usr/bin/gmake -f Makefile -j1 simulation
Why it is worth changing
The symptom is indistinguishable from a hang. A single ftn invocation on one of the larger modules can run for many minutes with no output and no new object files, so find build -newermt '-20 minutes' returns nothing while the build is perfectly healthy. I spent a while walking the process tree to establish that a build was progressing rather than stuck, and the answer was simply that it was serial.
Across a session that drives ./mfc.sh run repeatedly for several case-optimized configurations, the difference is hours of wall clock, on a login node that has the cores to spare.
Suggested fix
Default to something like min(nproc, 16) rather than 1, at least for the build performed inside run. If the conservative default is deliberate -- shared login nodes are a fair reason -- then it would help to say so in --help, and to have the build print the job count it is using so that "this is serial" is visible rather than inferred.
Found with Claude Code.
https://claude.ai/code/session_01HMJ7cycfo7kTFSFq5yhHLG
What happens
-j/--jobsdefaults to1:That is easy to remember for
./mfc.sh build, where you are consciously building. It is easy to forget for./mfc.sh run, which builds as a side effect of running -- and there the default means a full Cray GPU compile proceeds one file at a time:Why it is worth changing
The symptom is indistinguishable from a hang. A single
ftninvocation on one of the larger modules can run for many minutes with no output and no new object files, sofind build -newermt '-20 minutes'returns nothing while the build is perfectly healthy. I spent a while walking the process tree to establish that a build was progressing rather than stuck, and the answer was simply that it was serial.Across a session that drives
./mfc.sh runrepeatedly for several case-optimized configurations, the difference is hours of wall clock, on a login node that has the cores to spare.Suggested fix
Default to something like
min(nproc, 16)rather than1, at least for the build performed insiderun. If the conservative default is deliberate -- shared login nodes are a fair reason -- then it would help to say so in--help, and to have the build print the job count it is using so that "this is serial" is visible rather than inferred.Found with Claude Code.
https://claude.ai/code/session_01HMJ7cycfo7kTFSFq5yhHLG