Talk 9: Eric Holk

[rrnewton]

Time for practice talk: 14:17

[rrnewton]

I like the intro -- starts big picture but not to long, gets to the point.

[rrnewton]

I like big graphics rather than small -- but those arrows on the op DAGs are rather fat.

[samth]

Don't tell people not to read the slide -- don't show it if they shouldn't read it.

[samth]

Things get cut off on the bottom of the slide, which happens often on projectors. Avoid the bottom.

[rrnewton]

Re: "don't read the slide"

I think you can imply that by just saying "these are long, but they follow the same pattern -- I want to draw your attention to just a couple rules".

[rrnewton]

Because of projector washout issues -- could be good to have more contrast on the black writing / grey boxes. Lighter grey boxes would be fine.

[rrnewton]

"0th" versus "first" dimension... painful wording there

[rrnewton]

I really like the PLT redex screen shot -- but don't we need to know that evaluation is mixed with rewriting to understand why it ends up in a single destination state?

[rrnewton]

"This isn't a formal proof, we just ran it on some tests." -- Didn't we do a bit more than random testing? That is, we did "smallcheck" style as well as "quickcheck" style. We validated all rewrite orderings up to array size N. (What was N?)

So that is a "proof" but only up to N..

[rrnewton]

Why not pump up the plots to fill the whole slide if it's the only thing on the slide?

[rrnewton]

ARGH -- this is my bad, I sent out a bad template. It's got a tag line in the bottom from when I first used this template -- my first class taught at IU!

You can edit the master slide... I think that does it. If not, find replace across the document (replace with empty string) will do the trick.

[rrnewton]

This was easy to understand! That's my favorite property for talks to have ;-).

[rrnewton]

Dan: What can you do for "big data" applications?

Eric: this map-reduce style is similar to {google/hadoop}... we are targeting single machines but we could imagine scaling up to multiple machines.

[rrnewton]

Jason: how did it come out if you sliced mandelbrot the other direction?...

[rrnewton]

My question -- why do you not have an abstract representation of splitting "N" ways rather than just concrete numbers of splits (3, 2, whatever).

Eric: simplicity of doing code rewriting approach. Could do recursive splitting with knowledge of the machine. Could maybe turn it into dynamic splitting?

FYI, my answer on this one was that for auto-tuning purposes the concrete fissions give the compiler a "workspace" to rewrite, e.g., the two halves of the fold in divergent ways. This is something we want to explore. Conversely, a parameterized split is just an outer loop construct / nested data parallelism. That's good for a homogenous cluster -- and for many purposes -- but it doesn't do everything that our approach does.

[vollmerm]

You could probably talk about how the compiler does the splitting and how the runtime system schedules the kernels.

[rrnewton]

What people would like to see more of:

• I'd like to see more implementation
• perhaps walking through fissioning rules a bit more (I've got mixed feelings on that one)

[vollmerm]

@rrnewton The case against doing a general n-way split is that it complicates the types in the implementation. To answer that question he'd need to talk about how we do type-preserving rewriting.

[rrnewton]

Dan: thought the result was "unintuitive". And that there should be a good slogan like the Richard Gabriel's "less is more".