Talk 3: Michael Vollmer

[rrnewton]

No description provided.

[ccshan]

On an early slide, "side-by-side" should not be broken up by a line break. That bullet point should not be a sentence. How about a picture with two arrows labeled "embed"?

[jasonhemann]

There seemed to be a good deal of bullet point reading in the beginning. I've found if I'm writing long bulletpoints, those are supposed to be presenter notes, and the bullet should be a short phrase, or a phrase or two that summarizes the whole slide.

o General Autotuning Framework
o Integration tunes GPU kernels
o Whatever the third one was

[cgswords]

Conference Question: When you have a lot of "great fits", how do you pick one? Is it a guess-and-check thing?

---

• Lots of bullets, especially early.
• Talking about the internals, etc., could be better by showing the code or pictures. That said, you have a lot of "big" code slides that should be dropped or made more concise.
• You seemed to gloss over a bit of the important bits of Obsidian, like what a push/pull array is and what a warp is. Also, a lot of time was spent on Obsidian background, which didn't really come up in the rest of the talk. You could cut a lot of that discussion.
• Result code slide is not super-interesting. The compare function is the interesting bit, but was left off. (How does it change from application to application?)
• Get to the examples of auto-tuning faster? (Framework slide could go before code examples.)
• I'm not sure it's worthwhile to explain the search strategies in depth.
• Functional auto-tuning slide had great motivation in first paragraph that could go in an early slide.
• Why does getParam take a pair?
• soring => storing on Ext Eff slide 1
• Why present the applicative functor in extensive detail if it's bad?

[rrnewton]

Standard advice: text bad, code ok but not too much, pictures good ;-).

[rrnewton]

Does the genetic algorithm do more work per "iteration" than the others? Or are they all normalized so one tick on the X axis is one eval of the fitness function?

[rrnewton]

Why are simulated anealing and genetic WORSE than random on breadth first search?

[rrnewton]

Applicative tuning probably doesn't deserve that much time -- can't cover everything in the paper...

[rrnewton]

I didn't hear you say that KnownSymbol is for type level strings. (I heard "Type level lits".)

[jasonhemann]

What do we think about a picture of a tree with literal low hanging fruit, with the things you're doing as the name of the fruit?

[eholk]

You're reading your slides a lot. Have less text and more pictures.

I'd show an Obsidian code snippet as soon as you introduce Obsidian, before the bullet list.

On the Obsidian slide, pictures showing the GPU architecture would help understand the memory hierarchy, blocks, warps, etc.

It'd be a good idea to define push and pull arrays, since they are a central idea in Obsidian.

It was hard to tell with the technical difficulties, but this talk seems too long. I'd try to focus on key ideas, challenges and intuitions from the paper and let the audience read the paper for more details. One thing that could probably be trimmed is to not go into each benchmark individually but instead highlight the interesting or surprising aspects of the results.

[rrnewton]

Dan found typo -- "soring"

[samth]

• Lots of bullets and text everywhere
• Need more energy when you are talking.
• You spend a lot of time reading your slides -- the slides should be illustrations of your points, not your points themselves.
• "Reduction" benchmark is not easy to read
• What is the high-level point of your paper that you're trying to get across? That is not clear in this talk.
• Need signposting between portions of the talk.

[pnwamk]

just general comments:

• Fewer bullets and having any displayed iteratively would be better/clearer
• perhaps break down presentation of, or highlight portions of fancy graphs (a lot to take in at once)