ENH: Annotate mris_expand with thread usage #386
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one's a little weird, due to the multiple inheritance and also the inefficiency of multithreading in
mris_expand
.I noticed
midthickness
taking a long time while running tests, and I was pretty sure I'd seen that it could be parallelized.From watching
htop
and runningmris_expand
with a set ofOMP_NUM_THREADS
values, I see that generally you get about 65-75% core utilization, generally a bit under. We therefore overallocate threads by about 50% to make the core usage match the desired number of threads, occasionally peaking over but mostly sitting a bit under. This works pretty well for 2-12 desired threads (3-18OMP_NUM_THREADS
), but seems almost completely limited after that, with 24 threads utilizing maybe 13 cores at best. Therefore, I set this to max out at 12 for scheduling purposes.The memory usage of this tool is low and does not seem to increase noticeably with number of threads.
If
n_procs == 1
,str(1 * 3 // 2) == '1'
, so this does not interfere with people attempting to run things single-threaded.