-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[service] Add a reusable pool for backend services. #583
base: development
Are you sure you want to change the base?
[service] Add a reusable pool for backend services. #583
Conversation
Codecov Report
@@ Coverage Diff @@
## development #583 +/- ##
===============================================
- Coverage 88.36% 82.42% -5.94%
===============================================
Files 126 127 +1
Lines 7597 7739 +142
===============================================
- Hits 6713 6379 -334
- Misses 884 1360 +476
Continue to review full report at Codecov.
|
8c117ee
to
84c55ee
Compare
441e43d
to
8908d66
Compare
fc6a3c1
to
8576f96
Compare
23d3992
to
b59d070
Compare
b59d070
to
1a7016f
Compare
Rebased on development |
1a7016f
to
1fdad66
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (skimmed through the code, didn't understand it all but got some idea )
ff7e614
to
54a7a00
Compare
ee6ba16
to
58cb318
Compare
58cb318
to
9f61ba7
Compare
They are equivalent.
This adds gcc-v0 and the loop_tool-v0 environments to the gym.make(...) benchmark, and removes the benchmark for environment initialization from an existing service, as that is now the default behavior when using ServiceConnectionPools.
Add a base class for the ServiceConnectionPool that provides the same interface but does no caching.
9dc1220
to
fa2b50e
Compare
This removes the connection_pool target by merging it into the main package. This is needed to fix the CMake build.
tldr; Reuse backend services rather than throwing them away, reducing the cost of
gym.make(..)
from 109ms-662ms to 0.4ms-1.4ms (84x to >1000x speedups).Background
CompilerGym environments use a client/service architecture, where the client is a
gym.Env
object and the service is a subproces that implements the CompilationSession gRPC interface. At the moment, a new service is created every time an environment is created usinggym.make(...)
, and destroyed when the environment is closed. Starting a service is an expensive process (approx 112ms for LLVM and 600ms for loop_tool and GCC), and services can be re-used and shared between clients. There are even improvements to doing so as it means that caches can be shared between clients.Overview
This PR adds a
ServiceConnectionPool
class that implements a thread-safe pool for compiler service connections. This enables compiler service connections to be reused, avoiding the expensive initialization of a new service.There is a global instance of this class, available via the static
ServiceConnectionPool.get()
method. To use the pool, acquire a reference to the global instance, and call theServiceConnectionPool.acquire()
method to construct and return service connections:When a service is closed (by calling
service.close()
), it is automatically released back to the pool so that a future request for the same type of service will reuse the connection.Performance
By amortizing the cost of service initialization, the cost of
gym.make(...)
is just that of initializing the relevantCompilerEnv
class. For "dummy" C++ and Python environments, the speedup is 310x and >1000x, respectively. For the LLVM environment, which has an expensive class initialization, the speedup is 84.4x.Detailed microbenchmark results, compared to development branch: