Automatic Interception Interface

Automatic Interception Interface

Today, more and more software applications support a mode of operation which allows execution of several processes in parallel, taking advantage of multiple cores/processors on a local machine. Using Automatic Interception Interface, execution of these parallel processes can be accelerated without requiring any changes to the source code. With Automatic Interception Interface, IncrediBuild receives a list of process types (names) and a description on how to execute each type of process.

For example: An application “MyApp.exe” knows to execute in parallel, processes by the name of “DoSomething.exe”, according to the number of cores on your computer. Meaning that if there are  four cores on your computer,  Myapp runs each time four instances of DoSomething.exe. You can greatly accelerate the execution of this application in IncrediBuild, by telling MyApp that you have a large number of cores on your computer, e.g. 200, thus causing 200 tasks of DoSomething.exe to be sent to the IncrediBuild queue. In this case, instead of using only local cores, Interception Interface does automatic distribution of all the 196 remaining DoSomething.exe tasks across cores in the network.

The following steps should be performed for IncrediBuild to highly accelerate the total execution time:

  1. Write a small XML file that describes which process types names should run remotely and which process types are invokers responsible for executing sub-processes. (In this example, MyApp.exe is the invoking/spawning process, and DoSomething.exe is the process IncrediBuild should run on remote cores.)
  2. Indicate to MyApp.exe to run in parallel a large number of DoSomething.exe  tasks, and not only an amount equivalent to the number of local cores. This number should be at least as large as the maximum number of tasks that can be run in parallel on the cores in the network.
    It is also possible to specify a number larger (even much larger) than the number of parallel tasks that can run, for example, 1000 tasks, even if there are not that many cores in the network. In this case, IncrediBuild knows how to take all the 1000 requests and manage the queue itself according to the number of available cores.
  3. Execute MyApp.exe using the IncrediBuild IBConsole command, which should have been defined with a large number of allowed parallel processes in its command line.  This IBConsole command activates the entire job. The greater the number of tasks MyApp.exe executes in parallel, the greater the acceleration results of IncrediBuild.

IncrediBuild references the XML file to see how to execute each task in the job. When MyApp (that is defined as the invoker) runs in IncrediBuild, IncrediBuild listens to all calls that MyApp makes to the operating system, and every time it sees that MyApp invokes a process, it checks whether the process name appears in the XML file (created in step 1 above) as a process that should run remotely or as an invoker process that is responsible for process spawning. If it is specified to run remotely, IncrediBuild runs it on a remote computer instead of on a local computer. Note that if local cores are available, IncrediBuild can run tasks that have been defined in the XML file to run remotely, on the local machine.

The AllowIntercept function marks the invoker process that spawns sub-processes. For example, if a single process “a” executes a single process “b”, which executes process “c”,  both “a” and “b” are declared as “AllowIntercept”, while “c” is declared as “AllowRemote”.

Notes:

Advantages and Disadvantages

The benefit of this interface is that if the application that you want to accelerate (whether it is an application that you wrote or a third-party application) can already execute many processes in parallel, no changes to  the application source code are needed in order to accelerate the application using IncrediBuild.

The application executes as many processes in parallel as possible and lets IncrediBuild manage the execution queue, while distributing the processes according to the available cores in the network and the local machine.

The drawback is that if it is a third-party application that does not support multiprocessing, the processes run sequentially, and IncrediBuild does not know how to run these processes in parallel. If it is not a third-party application and its source code can be modified, you should change the source code so that it knows to run processes in parallel.

Note:

Use this Interface if:

  1. You are running a third-party tool or application that is executing multiple processes in parallel.
  2. You are running your own custom tool, which supports parallel process execution (or can be modified to support it), and you would like to accelerate the process through distribution over the network.

Contents of This Section: