Consider removing implicit pure definition with +=, *=

[abadams]

It makes the scheduling confusing. Why should you have to call update() when there's only one visible definition?

It's also a scheduling trap - there's an entire hidden stage there that you should probably be vectorizing/parallelizing.

[zvookin]

Is the proposal to remove this syntax entirely or to somehow make it so they produce a single stage reduction where scheduling automatically applies to everything? (E.g. by introducing the notion of a reduction where the pure stage is implicit and is scheduled the same way as the update operation.)

[abadams]

The proposal is to continue to allow the += syntax, but also require an
explicit pure definition. So

hist(im(r.x, r.y)) += 1;

would become:

hist(b) = 0;
hist(im(r.x, r.y)) += 1;

Which makes it clearer that there's a pure stage there than might need
scheduling.

On Thu, Jun 12, 2014 at 1:31 PM, Zalman Stern notifications@github.com
wrote:

Is the proposal to remove this syntax entirely or to somehow make it so
they produce a single stage reduction where scheduling automatically
applies to everything? (E.g. by introducing the notion of a reduction where
the pure stage is implicit and is scheduled the same way as the update
operation.)

—
Reply to this email directly or view it on GitHub
#334 (comment).

[zvookin]

This also relates to the discussion of implicit reductions (sum, maximum/minimum, etc.) and how while they seem to be a good idea language wise, they introduce problems for scheduling. It is unpleasant to easily write a piece of code and then have to write it in a longer form to make it performant.

I'm not sure the above has much impact either direction. It does seem like a good idea to make things more explicit, on the other hand I often initially forget to put in scheduling for all parts of a reduction even when they are written out so I'm not sure it really makes much difference.

One possibility would be to apply the same schedule to the pure stage if the first update stage is scheduled and the pure stage has not been scheduled. Sort of like how compute_root treats the storage level. This could be restricted to just the case where the pure stage was defined implicitly by an operator such as += or it could be made general. I'm not sure this actually works as the schedules for the two stages may need to mention different variables. To fix that might require converting the variable references to slot indices and using the same slot index on both stages. I'd have to dig a little deeper to decide if there is promise here...