Overview
Turbo Build Accelerator is a distributed build cluster designed to accelerate your c++ builds from within Visual Studio.
The goal is to reduce build times by distributing compilation over multiple machines, and allows more compilations to run in parallel. This relies on the assumption that all the machines are not at 100% usage at all times.
Build times are also reduced by caching build output (c++ object files) for later re-use. This avoids unnecessary compilations. The result is up to 3.5 times faster builds.
Faster builds are nice but you don't want to spend lots of time and effort changing your toolchain to achieve this. Turbo Build Accelerator works seamlessly from Visual Studio and with no additional effort. You can still use Visual Studio solutions and CMake.
Below is a screenshot of the Turbo Monitor GUI application. It shows a visualisation of a Turbo Build Cluster running on AWS EC2 machines. We can see the central Scheduler (in grey) and the attached Agent machines. The dark-green Agent 'EC2AMAZ-2QJLA9J' has initiated a build and it is delegating build jobs (compilations) to the other Agents. Each build job is a dark-green pulse around the Agent bubbles. Preparation jobs are shown as white pulses.
The Turbo Build Accelerator has the following components :
The CL.EXE Hook
The Visual Studio Integration Add-In for Turbo will direct your Visual Studio build to launch the Turbo Hook turbo-cl_x86.exe (or turbo-cl_x64.exe), instead of Microsoft's cl.exe. This provides a seamless build from within Visual Studio or from msbuild.exe.
The hook process will launch Microsoft's cl.exe on the local machine to pre-process your c/c++ source files. Then it communicates to the Agent to request compilation of the pre-processed source code. The Agent will launch Microsoft's cl.exe to compile the source code.
The Agent
The Agent receives build jobs from the CL.EXE Hook and submits them to the Scheduler.
The Agent will have build jobs scheduled to it by the Scheduler. It will process these by compiling source code to object files by launching Microsoft's cl.exe.
This work could be for a build running on the same machine or for a build delegated by a remote Agent.
Install the Agent on developer workstations and build servers. The turbo-agent.exe runs as a Windows Service.
The Scheduler
The Scheduler decides which Agent shall process the build job workloads, based on how best to utilise the spare capacity on the cluster and optimise your builds.
Each Agent in the Cluster is connected to the Scheduler and constantly reports its Status (such as number of build jobs running/pending, CPU% etc...). A scoring system is used to prioritise scheduling to an Agent with the build result already within its Cache, or to the least busy Agent.
The turbo-scheduler.exe runs as a Windows Service. There is only one instance of this process within the Turbo Build Cluster.
Ideally it should be installed and run on a server that does not have a Turbo Agent service installed. This is so its performance is not affected by build workloads. This will ensure smooth running of the Cluster.
The Monitor
An application giving graphical representation of the Agents and their workloads within the Cluster.
It is intended to provide an insight for Developers to the current workload of the Turbo Build Cluster and the progress of their own build(s).
Pre-processing and compilation jobs on an Agent are represented as 'pulses'. The colour of the pulse indicates which is the originating Agent of the work.
Communication
The CL.EXE Hook, Agent, Scheduler and Monitor communicate with each other via network sockets using JSON data payloads :
- The CL.EXE Hook communicates with the Agent.
- The Agent communicates with the Scheduler.
- The Monitor communicates with the Scheduler.
No network connections are made to the internet. Only to the above configured machines. The Firewall rules (inbound and outbound) created by the Installer are restricted to 'Local Subnet'. None of your source code will be transmitted to TurboDyne Systems Ltd.
Installation
The Turbo Build Accelerator has a single installer designed to install its components on each machine that will participate within the Turbo build cluster.
The Installer provides choice to install on a machine :
- The Scheduler (just one instance within the Cluster)
- The Agent
- Both Agent and Scheduler (not recommended except for simple testing)
The Installer provides the choice to create the necessary Windows Service(s) and Windows Firewall rules. Note: the Firewall rules (inbound and outbound) are restricted to 'Local Subnet'.
The Installer can be used in 'quiet' mode for easy automated deployment (e.g. by Terraform or Puppet). Examples of these can be provided upon request.
At the final stage of the Installer, you have the option to launch the installer for the Turbo Visual Studio Integration Add-In for seamless builds with Turbo.
Installation within your organisation has minimal impact with no need to provision additional resources such as an external database.
The Visual Studio Integration Add-In
This Add-In will provide the ability for Visual Studio builds to seamlessly utilise with Turbo Build Accelerator.
The screenshot below shows the menu option to choose if the VS Solution is to utilise the Turbo Build Accelerator:
The screenshot below shows the Add-In configuration options such as 'Build using Turbo by default':
Once a VS Solution is configured to build using Turbo, then builds invoked by msbuild.exe will also utilise Turbo Build Accelerator.
Additionally a command-line alternative to configure a VS Solution to utilise Turbo Build Accelerator is provided with the turbo-vs-solution-enabler.exe. This is useful within automated builds from a Continuous Integration tool like Jenkins.
Caching
The Turbo Build Accelerator can cache build output (c++ object) files for future re-use by either the same machine or a remote machine.
This powerful feature can significantly improve build times, since re-compilation can be avoided.
Each Agent holds a cache for fast local lookups. Additionally, to maximise performance, the Scheduler is aware of the Cache on each Agent, and can schedule build jobs to the agent with a cache 'hit'.
Ideally locate the Cache directory on a large capacity SSD for best results.
The Cache data is stored in-memory for fast lookups, and persisted in a SQLite database on each Agent and Scheduler machines.
The Cache database and file store is automatically managed to maintain a maximum disk space usage, on a LRU basis.
Build Cluster Performance considerations
Factors that can affect compilation performance within the Cluster (compared to a traditional non-distributed build):
- The number of c/c++ files within each VS Project. Fewer and larger Projects will see more improvement
- The size of the c/c++ files
- Compilation mode : Release mode will see more improvement than Debug
- Size of the Build Cluster
- The current workload on the Build Cluster
- Caching of compiled object files and the number of cache 'hits' within the build
- Maximizing build delegation throughout the cluster by having matching build environments on all machines
See here for performance benchmark results
