Is it very wrong to be drawing parallels between cilk_sync and thread.join() in C++?

@nassosterz I think that this is exactly the right parallel to be drawing! The way I've been thinking of Cilk, it's supposed to act as an additional abstraction layer to make it less difficult to reason about parallel computation – just like ISPC does, just in a different way.

Adding to @superscalar's comment, ISPC and Cilk both allow programmers to break their programs into smaller chunks so that programmers can best utilize the hardware without having to write low-level code (such as using intrinsic functions). From what I understand, ISPC mostly focuses on single-core SIMD performance. It offers an abstraction that takes multiple data and better utilizes the CPU with multiple instances of the same code. Cilk is another abstraction that focuses on multi-core parallelism but not single-core SIMD performance. It allows the programmer to specify the parts of the code that can be parallelized as well as the dependencies between them.

@nassosterz right, exactly. The first time that I saw Cilk code in lecture, cilk_spawn seemed identical to thread creation and cilk_sync seemed identical to thread joining. However, there are a couple subtleties here that Kayvon mentioned later in lecture that I found helpful:

• The difference between abstraction and implementation. In particular, cilk_spawn and cilk_sync can be correctly implemented as no-ops, and indeed any implementation of cilk_spawn and cilk_sync should produce an identical result to such serial execution. The spawn and sync commands provide an abstraction that indicates that the spawned calls may run concurrently with the caller, and must all complete before any commands after sync can execute, but nothing else.

• The introduction of a cilk-managed threadpool. In the cilk implementation discussed in class (and later on in the lecture slides), it looks like cilk (smartly) manages a task queue and a system-inferred set of threads organized in a threadpool that can grab available work from the task queues of other threads. This implementation detail is useful in analyzing how well cilk performs.

I don't entirely understand the question posed in this slide. Since cilk_spawn foo() needs to be async, doesn't that mean it cannot be implemented the same as a normal, serial function foo()

@potato. Think of an async operation as one that is potentially concurrent, not one that must be executed concurrently. Therefore, it is a valid implementation to implement the called child sequentially, followed by continuation, just like a normal function call.