Proof of concept; client/server architecture with shared cache #23
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.
When lifting many examples (such as Basil SystemTests) the 2 second evaluation environment initialisation is a significant penalty, this PR aims to avoid this, and allow sharing a cache between invocations. It should produce identical output.
--local
flag. This means there is only one evaluation env that lives in the server. The server only uses Lwt, so there is no parallelism in lifting, but there is enough time saved elsewhere for this to not matter.gtirb_semantics --serve
starts the server listening on a unix domain socketE.g. running all the gcc system tests gives a 2x speedup
compile & lift GCC SystemTests gtirb_semantics with env & cache initialized on each client:
make -j10 3145.71s user 457.15s system 991% cpu 6:03.26 total
compile & lift GCC System tests gtirb_sematnics with client-server & shared cache:
make -j10 1457.22s user 316.56s system 983% cpu 3:00.40 total
Server:
Note that there were only 2312 cache misses (91% cache hit rate) due to most of these programs being common setup code emitted by gcc.
Lifting cntlm:
client:
server:
We can see the client spends all its time asleep waiting for the socket (0.6s of work out of the 58s of elapsed time).
When executing locally we have a similar amount of time, since for large programs the initialisation doesn't play as much of a role in comparison to the IPC overhead: