Runtime Options

Number of Threads

The API allows adjusting the number of worker threads in the code: see CnC::debug::set_num_threads. You can also set the number of threads at runtime by setting the environment variable CNC_NUM_THREADS to the desired number of threads.

The given number must include the environment thread, e.g. n-1 worker threads will be created if CNC_NUM_THREADS is set to n.
Depending on the scheduling strategy, the runtime might actually spawn one or more extra internal helper threads. These threads will mostly be idle and should not have any significant effect on the other threads.


The CnC runtime comes with a selection of different scheduling strategies from which you can chose at runtime. At start-up time, the runtime selects the scheduler upon the evaluation of the environment variable CNC_SCHEDULER. Allowable values are

: tuner::affinity() is only evaluated by FIFO_AFFINITY. If your tuner provides affinity hints, you need to use FIFO_AFFINITY to actually make use of it.

The default scheduler is TBB_TASK. Depending on your application characteristics you might observe significant performance variations with different schedulers. Our experience is that in many cases either TBB_TASK or TBB_FIFO shows best (or best-equivalent) performance.

Scheduler Control

The CnC runtime reacts on a few more flags that can be controlled through environment variables:

Bypassing the Scheduler

The CnC runtime can optionally execute the first step-instance that is created by the current step (e.g. by putting a tag) right after the currently executing step. This successor step-instance will not go through the normal scheduling procedure and thus avoids overhead. The trade-off is that it can also limit parallelism. Hence this feature is disabled by default. To enable it set CNC_SCHEDULER_BYPASS to a number which is unequal to 0.

Next: Running CnC applications on distributed memory

 All Classes Namespaces Functions Variables Typedefs Enumerator Friends