You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most calls with pvcall are parallelized. Some other calls use serial = TRUE but then have boot::tsboot with its own parallelism. In general one can say that all the things from the paramval directory are to be run serial, with make -j 1. The rendering of the RMarkdown documents is single-threaded and could be parallelized with make -j $(nproc).
Use a second Makefile with the RMarkdown targets and call that with make -j $(nproc). This will improve throughput, but the dependencies have all to be satisfied before this can be done. Dependency handling inter-Makefile sounds like needless pain.
Not use GNU make but instead see whether Ninja-Build has this feature. Makefile generation should still be retained because system out of our control very likely do not have Ninja-Build installed.
Use a single Makefile and have processes communicate with some sort of semaphore to prevent oversubscription. That is likely going to end in deadlocks rather quickly.
The text was updated successfully, but these errors were encountered:
Most calls with
pvcall
are parallelized. Some other calls useserial = TRUE
but then haveboot::tsboot
with its own parallelism. In general one can say that all the things from theparamval
directory are to be run serial, withmake -j 1
. The rendering of the RMarkdown documents is single-threaded and could be parallelized withmake -j $(nproc)
.It seems that this mixture is not supported by GNU make, see this Stack Overflow question.
I currently see the following options:
Use a second
Makefile
with the RMarkdown targets and call that withmake -j $(nproc)
. This will improve throughput, but the dependencies have all to be satisfied before this can be done. Dependency handling inter-Makefile sounds like needless pain.Not use GNU make but instead see whether Ninja-Build has this feature.
Makefile
generation should still be retained because system out of our control very likely do not have Ninja-Build installed.Use a single
Makefile
and have processes communicate with some sort of semaphore to prevent oversubscription. That is likely going to end in deadlocks rather quickly.The text was updated successfully, but these errors were encountered: