Dot Product Thoughts (original) (raw)
Richard Warburton richard.warburton at gmail.com
Thu Apr 18 17:34:32 PDT 2013
- Previous message: Dot Product Thoughts
- Next message: Dot Product Thoughts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
Thanks for your replies, most appreciated.
- 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>
- Previous message: Dot Product Thoughts
- Next message: Dot Product Thoughts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]