Talk 10: Abhishek Kulkarni

[rrnewton]

The talk time was ~ 28 minutes.

[rrnewton]

Why is one-armed / two-armed important here? Maybe we will learn...

[rrnewton]

I dunno if it can be said that "task parallel" frameworks universally provide fork/join. But yeah, there is almost always some way to wait for a task. Whether it's strictly nested, terminally strict, or just pre-task completion bits.

[chamibuddhika]

I think "lightweight" threads should be mentioned somewhere in the slide (Task Parallel Frameworks).

[rrnewton]

Slide 4 says "spawn" overhead, but we just said "fork"... maybe normalize these, or make a distinction.

For instance, if you want to be really explicit if when you introduce cilk_spawn you can say cilk_spawn = fork

[ccshan]

In the slide before the Cilk slide, "Threads" at the bottom is not entirely bold. Also I'm not sure what it means for a task/thread to be blocking/non-blocking, but I might not be the right audience for this.

[rrnewton]

Mentioned "leaves the core idle".. haven't yet mentioned possible deadlock threats from violating the user / task-scheduler contract by blocking the scheduler's worker thread....

[chamibuddhika]

I might have missed it. Was "work first stealing" explained a bit in the Cilk intro? This is one of the main implementation aspects of Cilk AFAIK.

[rrnewton]

We probably defined "fiber" before slide 11, but I missed it.

[chamibuddhika]

What is "team leader" used for, in the newly introduced fields?

[rrnewton]

Huh, I forgot we look in the pause list for work -- what does that mean? Pause fibers aren't ready to run!

[rrnewton]

Oh, right that doesn't mean steal/activate the paused task itself ... but look in its shadow stack / cilk stack for stealable continuations! That would be great to clarify.

[rrnewton]

The two ends of that overhead curve are probably noise... should fess up to that if asked. It shows the SAME benchmark both at the "speedup" and "slowdown" ends.

[rrnewton]

May want to mention that the overhead that does occur with cilk_sleep is because of context switching. Even though the cpu isn't left idle, it's still wasting time doing longjmp/setjmp nonsense.

[rrnewton]

20 minute mark -- on the "Scheduling Microbenchmarks"

[rrnewton]

Looking at the parfib(30) benchmarks... may be good to hammer home the "eager vs lazy" thread context creation. Eager is pessimistic, lazy is optimistic, speculating that you've got a non-blocking task, and only creating thread context when absolutely needed.

Also hammer home the extent of this difference -- this is >3 orders of magnitude!! (log log plot)