loop customization: a key challenge

[Aleksey Shipilev]

On 09/10/2012 09:28 PM, John Rose wrote:
> There is an important optimization challenge coming up when lambdas
> are combined (as they are intended to be combined) with bulk data
> processing libraries.  I call this optimization challenge "loop
> customization".

Thanks for a nice writeup!

Actually, we thought about this as well in the context of
lambda-accepting methods, the prime example being bulk operations. This
is something bugging us as well.

> (Can anyone propose a previously coined, commonly used term instead
> of loop customization?  Please read on…)

I think this is not about the loops per se, albeit the impact is mostly
visible in the loops, where you bang yourself of this issue over and
over and over again. But this applies to any other (linear) optimization.

> With closures, there is another option for triggering customization,
and that is partial application. [1] L0 should create a customized inner
loop L1+X, not by eventually calling X from L1 inside each worker
thread, but by partially applying L1 to X at top level, before splitting
the workload.

This looks like to attempt to translate the argument type dispatch [*]
to receiver type dispatch which we are able to optimize well already. Do
we have other options for syntax/semantic convention to tell VM "see
this argument? You better specialize on it's type"? Given John's
conversion is probably forced by the user, I think syntactical brevity
is the significant concern even for hard-core library developers.

-Aleksey.

[*] Granted, the dispatch for the copies of the same method, but each
with specialized type constraints.