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)

[rrnewton]

I was a bit confused by:

produce() -> ivar_put() -> ivar_get() -> consume()

This was confusing because it makes it look like there's a single ivar and it forms a global barirer identical to the cilk_sync.

Maybe some way to make it clear that the IVars are per-element, or per-tile.

(at 24 min now.)

[rrnewton]

Isn't wavefront also an instance of "sync elision"?

[rrnewton]

On Wavefront we've got error bars... but how many trials is this???

[rrnewton]

The server benchmark on slide 30 doesn't have the word "server" on it but it does have "client".

[rrnewton]

"legacy support" was mentioned ... was it defined? Maybe it's ok for it to be informal.

[eholk]

On Opportunity Cost graph, what is the X axis?

I liked the thorough performance evaluation. I like that you took the time to introduce each benchmark, describe what the benchmark is supposed to show and then discuss the results.

[cgswords]

We spent a bit of time on timing results. It's cool that you're winning, but... lots of focus on the details.

Also, less pop-in text. Displaying whole slides at a time is probably fine. (Also, the fib tree can all appear at once, etc.)