Does cilk use the implementation of threads such that it would be an ideal set up to execute "n" cilk spawn calls on a system that has "n" hyperthreads (like 8 calls on our 4 core, 8 hyperthread myth machines), or do cilk calls behave more like tasks in how ISPC schedules work?

@jyeung27 I think another way to rephrase your question would be: Does each cilk thread spawned by cilk_spawn correspond to 1 underlying hardware thread for its whole lifetime, or if there is a pool of underlying hardware threads that are launched and act like workers, like in the case of the ISPC launch keyword?

@jyeung27 Actually, I wanted to make another comment to respond to your comment. I think there are as many threads spawned as there are calls to cilk_spawn, so it is not aware of an "ideal setup".

@pslui88 @jyeung27 It seems to me that cilk_spawn creates a separate thread of execution, so if you're defining ideal as each thread is always assigned to a processor and never idle, then I think they behave closer to how @jyeung27 describes them, closer to the implementation of threads rather than ISPC tasks.

Is cilk smart enough to take advantage of vector operations or is there a way to use cilk with ispc? Or do each have their own distinct advantages?

@tp I was thinking about this at the end of the lecture. There is not a guarantee that Cilk would even benefit from SIMD instructions because Cilk allows for any arbitrary function to fork. For instance, if we forked a different function every time, we generally could not even use SIMD instructions to compute for multiple functions (because they are different). Or if the function forked is always the same but would lead to poor SIMD utilization we might opt out. Yet, in a recursive use case like Quicksort, where we spawn a group of threads that execute the same function with good utilization, then the door is open for SIMD.

I was thinking of a Quicksort where the first recursive calls would fork and spawn normally but once the recurse tree hits its 3rd level, we have 8 logical instructions streams with the same code to run for the same amount of time. We use one thread for this level, two threads for the next level, and so on (obviously imposing similar limits on trivial parallel work).

Not sure if Cilk can do such a thing though.

@tp After reading @lexicologist's post two slides up, it does look like Cilk can do such a thing!

The notion of a "fork" reminds me of multiprocessing. Is there any relationship between that and cilk_spawn?

To me, the designation of cilk_spawn as a "fork" is no accident, and is indeed on a similar abstraction level to that of multiprocessing. The main similarity between the two is that the work done in parallel need not be the same instructions, or code. As @l-henken discussed above, any arbitrary function could be cilk-forked.

Of course, future lecture slides discuss cilk-fork in the context of running the same function in parallel, which doesn't support my claim above. If anyone has any further discussion that shows that the name "fork" doesn't have a particular abstraction associated with it, I'd love to hear it!

For the sake of analogies, it's also worth noting that cilk_sync behaves like the barrier synchronisation primitive we learned about last lecture.

It would be interesting if cilk allowed you to specify different forks in a function, where you would join to that fork, although it seems this isn't possible.