| Note |
|---|
Important! To be accelerated by IncrediBuild Linux, build tools must have the capability of executing multiple processes in parallel. In most build tools, a multi-process execution command already exists, such as the -j command option in Make. |
In order to execute your builds using IncrediBuild Linux, you do not need to make any changes to your existing source code or build scripts. All you need to do is to add to your tool execution command the following:
...
To instruct your tool to execute multiple processes in parallel, add a number to the multiprocessing command. For example, if you enter -j 200 for Make, you are instructing Make to execute up to 200 processes in parallel. IncrediBuild will then take hold of the process queue, and distribute the relevant processes across available cores on Agent machines in your network.
Note: Some build tools do not have a specific command option for multiprocessing execution. In this case, you need to make changes to certain configuration files in order to enable the execution of multiple processes in parallel.
For example, to execute a build that is running via Make, enter the following:
ib_console make -j <number_of_processes_to_run_in_parallel>
> To execute a build using IncrediBuild Linux:
In the terminal, go to the directory of the build you want to execute.
In your build directory, enter:
Code Block language bash ib_console <your_build_tool_command> <multiprocessing_command> <number_of_processes_to_run_in_parallel >Note: To maximize the task parallelization and acceleration, it is best practice to configure a high number of processes for the multiprocessing command, even if you will not use all of them. It is recommended to set the value of -j or any other multiprocessing command to at least double the number of available CPU cores in your IncrediBuild Environment.
Your build is executed with IncrediBuild Linux, and its processes are distributed across the available cores in your IncrediBuild Environment.
For example:
ib_console make -j 200
...
Note: A performance improvement may not appear as expected after the first build execution, and it is recommended to start measuring your build time improvement from the second execution. The reason for this is that the builds you execute use the file cache of the remote Helper Agents, and fill them with data. Consequently, after the first build execution the network traffic and file copying processes are drastically reduced, and this reduction is manifested in a performance boost in subsequent builds.
...