Cilk++ does not recognize the number of cores

Cilk++ does not recognize the number of cores


Recently, I build the programs written in cilk++ on AMD, 64 bit Linux.
The program compiles well, i use -m32 to get the 32 bit version. I use gcc-4.2, and g++-4.2.
But I do not get any parallelism, i.e -cilk_set_worker_count switch has no effect, it seems that cilk++ compiler is not able to pick up the number of cores available ...

On the other hand, I compile the same programs on intel 32 bit Linux using same gcc-4.2 and g++-4.2 version. In this case, I build my program once again in this machine and I do get a speedup, and the switch
-cilk_set_worker_count seems to work.

In both the case, I try to build on same libraries, only difference is that one is 64 bit with 32 bit output and the later one is 32 bit.

My question is : Is it possible for Cilk++ compiler to be unaware of the number of cores and if yes when does it happen ?

Thanks in advance !

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

Hi all, Finally, I solved the problem. I was using a multi-threaded library inside my application parallelized with cilk++. Once I set GOTO_NUM_THREAD=1, I got the scalability ... I tried withGOTO_NUM_THREAD=2 and the program did not scale. Why cilk++ does not operate with Gotoblas which is a pthreaded library ?Or possibly, I should try on machine with more cores (>8 cores, which i use now)Thanks,Pk

I don't believe Cilk++ has been tested with Gotoblas. However, it sounds like Gotoblas is using all of the system resources. If that is so, then there may be nothing left for the Cilk++ library to use.

On Linux, the Cilk runtime uses the following code to detect the number of cores:

unsigned __cilkrts_cpu_count (void) {
const char *count = getenv("CILK_NPROC");
int nproc = 1;
if (count)
nproc = atoi(count);
nproc = get_nprocs();
if (nproc < 1)
nproc = 1;
return nproc;

I can't begin to guess why your threading package is having problems with this. However, there are general issues in mixing Cilk with other threading packages.

Using Cilk within a program that's already multithreaded raises the question of how the threads are apportioned. When you create a Cilk context and then enter Cilk, the Cilk runtime will create a thread per core to do it's work in. If your application also uses some other threading package and then creates multiple Cilk contexts and calls into Cilk, the Cilk runtime will create a thead per core for *EACH* of the Cilk contexts in each of the threads. The can lead the to oversubscription and your application may spend too much time context switching. On the Cilk team we refer to this as a combinatorial explosion of threads.

The Cilk V2 runtime avoids this by doing away with the Cilk Context from Cilk V1.1. There is now the concept of "user" threads and "worker" threads. When the Cilk runtime starts up, it creates a worker thread per core, just like in the previous version of Cilk. A user thread is some other thread that calls a Cilk function. As part of that function's prolog, it will be "bound" into the Cilk environment, initializing the Cilk runtime if it hasn't happened yet, and the worker threads will start trying to steal work from it. Unlike Cilk V1, any syncs in that function are guaranteed to be continued on the original user thread. When that function exits, the thread is automatically "unbound" and the worker threads are suspended when there are no more bound user threads. User threads are also prevented from stealing, so they aren't delayed doing work for some other thread.

The guarantee that you'll continue on the original thread in the outermost Cilk function fixes thread local storage issues around calls into Cilk. But there are still no guarantees on what thread you're running on after crossing any strand boundry (a cilk_spawn, cilk_sync or cilk_for) on any inner functions. So use of thread local storage is still discouraged.

Support for Cilk is being integrated into Intel's C/C++ compiler for
both Linux and Windows. You can request to join the beta at

- Barry

Leave a Comment

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