Dot Product Thoughts

[Richard Warburton]

Hi,

Thanks for your replies, most appreciated.

1. There's a Double::sum, but no Double::multiply, etc.  I appreciate you
> have to stop somewhere, but is sum the place to stop?  Might be worth
> adding other basic arithmetic operations.
>
>
> Yes, we definitely stopped in the wrong place :)
>
> Sensible would be the ability to express all built-in operators as
> functions so they can be used as reducers.
>
> I'm a bit confused: are you describing a language change that would allow
any operator to be used as a function, or adding more static overloads to
primitive classes and Strings?

> 4. A performance comparison with a trivial imperative example resulted in a
> ~16x slowdown moving to lambdas.  I'm willing to take some performance hit
> for the nicer code, but 16x is a lot higher than I would have expected or
> hoped for.  I'll try to have a look at some more 'real world' examples in
> future, but even then being this much slower on mathematical problems will
> cause some people trouble.
>
>
> The real cost is in replacing the primitive operators with method
> invocations; the cost of the streams framework is a smaller component.
>
> Vector reduce is *almost* a microbenchmark, in the sense that the leaf
> calls do almost nothing (one CPU instruction).
>
> So, like a microbenchmark, it really stresses the JIT and the overheads in
> the framework, notably primitive boxing and (probably) array storage.
>  Unlike a microbenchmark, it's something you might really want to do.  Or
> at least, it is similar; I would say a segmented multi-reduce (during a
> sparse matrix multiply) is more plausible, and that starts to get away from
> what Lambda streams are about.  Still, plain mega-reduce is a good test
> case.
>
> To optimize your loop, the JIT must inline everything on the hot path, and
> avoid a bunch of hazards, including: putting values in temporary Object[]
> arrays, dropping through megamorphic interface calls (in common code),
> keeping values in boxes, spending compiler resources on cold paths.  The
> JIT team is gearing up for this, and it's going to be an exciting project.
>

I appreciate this is a series of non-trivial problems, so I have two follow
up questions:

* What should I avoid when Java 8 is released?  So given the current state
of play that the implementation of method inlining isn't meeting its full
potential, you've outlined a basic scenario where you get poor performance:
when the leaf calls do very little.  Internally (or even better publicly)
have people identified what they would think of as the "sweet spot" for
mathematical operations?  In other words: where do you think the streams
framework retains the idiomatic benefit and has a more limited performance
penalty?
* Can people do anything to help?  Are you hoping for more performance
problems to be presented, or are there enough already, known well, and the
issue is basically in the JIT team solving the issues that John has
outlined above?

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>