Dot Product Thoughts (original) (raw)
Brian Goetz brian.goetz at oracle.com
Thu Apr 18 16:30:31 PDT 2013
- Previous message: Dot Product Thoughts
- Next message: Dot Product Thoughts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 suspect that the naming convention we've started down the road of (sum) may not scale as well as we'd like. Peraps that should be reconsidered now as we now have methods like IntStream.sum() and no longer have as much need for Integer::sum when used as a reducer; perhaps it should be renamed opPlus or opSum or some such.
2. There appears to be a zip function now, but with no overloads for primitive streams. I managed to guess at Streams.zip as the location, so one data point, but good news on that front.
Yeah, this one is on the fence. We should go one way or the other.
3. If I have an double[] is there is a cleaner way of making a DoubleStream than adding every element to the builder?
Arrays.stream(double[])
or, alternately, if we didn't have that,
Streams.intRange(0, array.length).map(i -> array[i])
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. Now, where'd I put that jar of Inline Sauce...
Notes: * When I profiled the hotspot wasn't in boxing/unboxing but Iterator.forEachRemaining - pretty hot as well, ~ 95% of execution time. I suspect the conclusion is that the computational work of actually performing arithmetic is entirely dominated by the cost of iteration in the framework.
Not iteration, invocation.
- Previous message: Dot Product Thoughts
- Next message: Dot Product Thoughts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]