Cilk worker scheduling

Cilk worker scheduling


I would like to understand better how Cilk scheduling works. 
I am not sure how to phrase this question so I give it my best.

I have downloaded the latest Intel Cilk runtime release (cilkplus-rtl-003365 -  released 3-May-2013).
I use the classical Fibonacci example in Cilk.

I wanted to know on what CPU core each worker executes.
To Fibonacci example, I added a function that checks CPU affinity for every worker as in here:

“printf” is located in “int fib(int n)” of the Fibonacci sample code.
I get WORKER ID using “__cilkrts_get_worker_number()”
While the program runs, I print each WORKER's ID and the CPU core affinity of each worker. 

However, the result surprises me.
I expected that some of the workers would run on different CPU cores but it seems that all workers are running on the same exact CPU core. 

For example, I get this for every “printf” when running “./fib 30”:
***** WORKER ID: 0 on CPU core: 7 *****
***** WORKER ID: 3 on CPU core: 7 *****
...(repeats sa long as some binary is executing) ...
***** WORKER ID: 0 on CPU core: 7 *****

I have repeated these tests using PBBS ( and get the same results.
I did similar experiments using OpenMP (Windows and Linux) and I saw threads executing on different CPU’s.

My system is:
Debian GNU/Linux 7.0 running kernel 3.2.49
Available CPU schedulers are: noop, deadline, cfq - the system is running cfg
AMD FX-8150 (8-core)

I think, I might be missing or misunderstanding something here. 
Is there a “preferred” Linux CPU scheduler for Intel Cilk runtime?
Do you have any advice or suggestion? 

Thank you for your time,

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The Cilk runtime should not be setting the affinity for any of the system worker threads. It creates them and leaves it to the OS to assign them to idle cores. The benefit of this is that if a core becomes busy for some reason, the thread is free to migrate to some other core for execution.

Your printf statement is forcing synchronization of your threads, and it's possible that the OS is not seeing any pressure to move the workers to other cores.

You might try removing the printf statement, and then running the "top" command. If you see more than 100% CPU, you're using multiple cores.

   - Barry

Leave a Comment

Please sign in to add a comment. Not a member? Join today