This seems to imply that running continuation first is not ideal if the cilk_spawn calls are in a loop (which I agree since a very large portion of common programs are loops). Are there more arguments in favor of running the child first? Could running continuation first ever be more performant because they don't need to swap out the registers and push/pop things from the call stack as often?

I do not fully understand the last bullet point that execution order is different. Is it because that we do not know which function in the work queue will be stolen and executed first in case of multiple threads?

I was also confused on why the execution order is reversed, since we are referring to each thread as having a work queue, not a stack? If it’s a queue, I think the work order should be the same as the order the work was enqueued?

In the previous slides it was mentioned that cilk_sync is implicit at the end of each function. Here, why is cilk_sync not assumed by the compiler at the end of each for iteration?

In child stealing, the code unfolds all the child items in the work queue when (in a two thread system) only one child item is actually required to be unfolded at a time for 100% utilization. This can be unnecessary sometimes and continuation stealing is better in such cases.

@jaez @apappu in slide 48 it's noted that the local thread puses/pops from the tail of the queue (bottom), while work is stolen from the head (top). So, when there is no stealing the queue (which is actually a double ended queue) is treated like a stack, LIFO. That would explain why the work gets done in the order foo(N-1), foo(N-2), ... foo(0) by a single thread.

@It's me! I think that we're assuming this is a code chunk within a larger function. The loop iteration isn't a function in and of itself.

I am a bit confused by what "breadth-first traversal of call graph" means here.

@jasonalouda, from my understanding its just making sure to evenly distribute the work (instead of having all the work cluttered up).