spawn depth

spawn depth

Dear all, is the 1024 limit to spawn depth still valid? If so, is there any way we can run a sanity check to see whether we have reached that level while using a cilk_for? Thanks.

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

Yes, the 1024 limit is still in place.

There's no easy way to check your spawn depth.  The only thing you could do is to pass in a depth counter and increment it each spawn.

Of course, the runtime sources are available on the website at  You should be able to change the limit by changing ltqsize in global_state.cpp.  It's currently hardcoded to 1024.

    - Barry

Unless you've got a *lot* of nested cilk_for's you shouldn't be coming near the spawn depth limit.  cilk_for implements a divide-and-conquer algorithm that should divide your data into approximately 8P grains.  That usually results in a spawn of 3.

    - Barry

Roughly speaking, a cilk_for over n iterations decomposes into a divide-and-conquer tree that has a spawn depth of at most lg n, give or take a small additive constant.   To reach the spawn depth limit with a cilk_for loop, you would need something like a loop of n = 2^1000 iterations.  In other words, it seems highly unlikely that you are reaching the spawn depth limit with only a cilk_for.  Usually, you need to be doing many explicit _Cilk_spawn statements to reach that limit.
There are probably ways to reach into the runtime library, retrieve the current worker, and check the address of the worker's head and tail pointers.   But I don't recall if these will require you to modify sources.

If you were using icc, then it is also possible to look at the length of the current pedigree, and get an approximate value for the spawn depth.

Is there a particular issue you are trying to debug?

Thanks to both. Alright, I never thought of recompiling the runtime... that may come handy at some point in the future. Thanks.

Jim, yes, we're trying to debug some cilkplus code with using gcc-cilk, and it's giving us 

./../../gcc-cilk-src/libcilkrts/runtime/sysdep-unix.c:725: cilk assertion failed: sd->stack_op_routine == NULL

we thought we may have achieved the spawn limit, but if as Jim says the cilk_for should be doing 2^1000 iters to reach the limit, then that's out of the question... maybe we're just running out of mem or segfaulting somewhere else.


Nope.  That's the TBB-interop stuff.  It's flagging a logic flaw.

    - Barry

Agreed. I don't know what the "tbb-interop" stuff is, but I agree it's a logic flaw somewhere else. In any case, being so wrong helped me understand a few other things about cilk. Thanks again.

Trust me, you don't want to try to debug the TBB-interop stuff.  Can you give us a (small) program that reproduces the problem?

    - Barry

Oh, ok. I thought you meant a logic flaw in *my* code. And no, I wouldn't touch the TBB stuff with a ten-foot pole :)

Let me debug my code a little bit longer... if the problem persists, I will try to reproduce the error and send it your way.

Leave a Comment

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