In addition to cilk_sync and cilk_spawn, cilk also has it's own version of foreach, named cilk_for (https://en.wikipedia.org/wiki/Cilk#Parallel_loops). It seems to perform a map that splits up computation. This also raises the question of granularity, which the user can optionally set. In practice, this abstraction is implemented as spawning chunks of the for loop.
tclarke
I am a little confused as to why Cilk was used in this lecture. I understand it is a good language to learn since it allows the run-time environment to decide how to divy up work between processors. But couldn't the cilk_spawn and cilk_sync functions be replaced by pthread_create and pthread_barrier_wait functions?
bpr
@tclarke, as this slide notes, cilk_sync corresponds better to pthread_join. That said, the advantage of using Cilk is that it already has support for load balancing, distributing and scheduling tasks. In that context, we can discuss how a modern runtime (i.e., Cilk) handles these problems and what the possible design decisions are.
If the lecture only used pthread routines, then we would also have to introduce scheduling and synchronization routines in order to schedule the threads. But it is a good question to consider.
Iamme
@tclarke One difference between cilk_spawn and pthread_create is that cilk_spawn isn't actually guaranteed to run anything asynchronously. It's just an indication that the work is independent of what follows it (before a cilk_sync at least), and therefore CAN be run asynchronously. I assume that this means that Cilk determines when it is actually beneficial to run the code asynchronously and doesn't do so when it's a bad use of resources or a bad space/time trade-off.
caiqifang
Can I interpret the cilk_spawn and cilk_sync as the ISPC task bulk launch and ISPC task sync? What are some of the difference in both abstraction level and implementation level? Thanks guys.
Iamme
One notable difference between cilk_spawn and launch is that launch... launches a bunch of tasks at once while cilk_spawn only spawns (at most) one new task. Based on how cilk_spawn is used in the lecture notes, this seems important since cilk_spawn is often used recursively, being called many times in a row, which I expect isn't good for launch. My guess would be that launch has more overhead because of its ability to launch multiple tasks and because of the features it has as a result of that. I also got the impression from the lecture (perhaps based on nothing) that cilk_spawn is somehow more granular or small-scale than launch or pthread_create, but I have no idea if that's really true.
Can anyone confirm or deny anything about overhead?
In addition to cilk_sync and cilk_spawn, cilk also has it's own version of foreach, named cilk_for (https://en.wikipedia.org/wiki/Cilk#Parallel_loops). It seems to perform a map that splits up computation. This also raises the question of granularity, which the user can optionally set. In practice, this abstraction is implemented as spawning chunks of the for loop.
I am a little confused as to why Cilk was used in this lecture. I understand it is a good language to learn since it allows the run-time environment to decide how to divy up work between processors. But couldn't the cilk_spawn and cilk_sync functions be replaced by pthread_create and pthread_barrier_wait functions?
@tclarke, as this slide notes, cilk_sync corresponds better to pthread_join. That said, the advantage of using Cilk is that it already has support for load balancing, distributing and scheduling tasks. In that context, we can discuss how a modern runtime (i.e., Cilk) handles these problems and what the possible design decisions are.
If the lecture only used pthread routines, then we would also have to introduce scheduling and synchronization routines in order to schedule the threads. But it is a good question to consider.
@tclarke One difference between cilk_spawn and pthread_create is that cilk_spawn isn't actually guaranteed to run anything asynchronously. It's just an indication that the work is independent of what follows it (before a cilk_sync at least), and therefore CAN be run asynchronously. I assume that this means that Cilk determines when it is actually beneficial to run the code asynchronously and doesn't do so when it's a bad use of resources or a bad space/time trade-off.
Can I interpret the cilk_spawn and cilk_sync as the ISPC task bulk launch and ISPC task sync? What are some of the difference in both abstraction level and implementation level? Thanks guys.
One notable difference between cilk_spawn and launch is that launch... launches a bunch of tasks at once while cilk_spawn only spawns (at most) one new task. Based on how cilk_spawn is used in the lecture notes, this seems important since cilk_spawn is often used recursively, being called many times in a row, which I expect isn't good for launch. My guess would be that launch has more overhead because of its ability to launch multiple tasks and because of the features it has as a result of that. I also got the impression from the lecture (perhaps based on nothing) that cilk_spawn is somehow more granular or small-scale than launch or pthread_create, but I have no idea if that's really true. Can anyone confirm or deny anything about overhead?