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
When compiling a parser we spawn external processes to compile generated C++ files and link them into an HLTO file. We make sure to not spawn more than nproc parallel processes, but even on powerful systems especially the compilation jobs can overwhelm the system when multiple spicyc/spicyz invocations are active at the same time, e.g., in builds of larger setups with recursive invocations of make, or when executing btest with -j. Users then work around this by specifying a small value for HILTI_JIT_PARALLELISM to control the worst case, but likely slowing down the average case.
GNU make implements a job server which can be used to control parallelism in such scenarios.1 The server maintains a limited set of "tokens" which programs invoked by makeobtain in order to launch jobs. With that the top-level parallelism from make -j<N> can be respected.
We should consider adding functionality so JIT can act as a job server client, ideally using a library which implements the server interaction. If a job server is detected we would override the current behavior of using the maximum concurrency of the hardware; HILTI_JIT_PARALLELISM/HIT_JIT_SEQUENTIAL would still override this behavior.
When compiling a parser we spawn external processes to compile generated C++ files and link them into an HLTO file. We make sure to not spawn more than
nproc
parallel processes, but even on powerful systems especially the compilation jobs can overwhelm the system when multiplespicyc
/spicyz
invocations are active at the same time, e.g., in builds of larger setups with recursive invocations ofmake
, or when executingbtest
with-j
. Users then work around this by specifying a small value forHILTI_JIT_PARALLELISM
to control the worst case, but likely slowing down the average case.GNU make implements a job server which can be used to control parallelism in such scenarios.1 The server maintains a limited set of "tokens" which programs invoked by
make
obtain in order to launch jobs. With that the top-level parallelism frommake -j<N>
can be respected.We should consider adding functionality so JIT can act as a job server client, ideally using a library which implements the server interaction. If a job server is detected we would override the current behavior of using the maximum concurrency of the hardware;
HILTI_JIT_PARALLELISM
/HIT_JIT_SEQUENTIAL
would still override this behavior.spicy/hilti/toolchain/src/compiler/jit.cc
Lines 506 to 532 in f06bd93
In order to make this work in BTest invocations we would need to implement support for
btest
to act as both a job server as well as client.Footnotes
Ninja is in the process of implementing support for it to be a client as well as a server itself. ↩
The text was updated successfully, but these errors were encountered: