Turbo Build Accelerator for C++

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 reports its Status (such as number of build jobs running/pending, CPU% etc...)

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

This application gives a graphical representation of the Agents and their workloads.

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.

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.

The Installer can be used in 'quiet' mode for easy automated deployment (e.g. by Terraform or Puppet).

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.

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.

Ideally locate the Cache directory on a large capacity SSD for best results.

NOTE: the caching facility is due to be in the next release (Sept 2025)

Build Integrity

When distributing a build there is a risk of corruption of the build by a mismatched build environment on a remote machine.

Turbo prevents this by only delegating to remote machines with a matching build environment. The matching criteria includes:

• The VisualStudio Version
• The Target Architecture
• The VC Tools Version
• The Windows SDK version

To maximize the build delegation throughout the cluster it is best to have matching build environments on all machines.

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
• 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 (the caching facility will be in the next release [Sept 2025])
• Maximizing build delegation throughout the cluster by having matching build environments on all machines

See here for performance benchmark results