Primitive streams

[Remi Forax]

On 12/28/2012 06:55 PM, Brian Goetz wrote:
> The implementation currently has two versions of streams, reference 
> and integer.  Let's checkpoint on the primitive specialization 
> strategy, since it does result in a fair amount of code and API bloat 
> (though not as bad as it looks, since many of the currently public 
> abstractions will be made private.)
>
> So, let's start with the argument for specialized streams at all.
>
> 1.  Boxing costs.  Doing calculations like "sum of squares" in boxed 
> world is awful:
>
>   int sumOfWeights = foos.map(Foo::weight).reduce(0, Integer::sum);
>
> Here, all the weights will be boxed and unboxed just to add them up. 
> Figure a 10x performance hit for that in the (many) cases where the VM 
> doesn't save us.
>
> It is possible to mitigate this somewhat by having fused mapReduce 
> methods, which we tried early on, such as :
>
>   foos.mapReduce(Foo::getWeight, 0, Integer::sum)
>
> Here, at least now all the reduction is happening in the unboxed 
> domain.  But the API is now nastier, and while the above is readable, 
> it gets worse in less trivial examples where there are more mapper and 
> reducer lambdas being passed as arguments and its not obvious which is 
> which. Plus the explosion of mapReduce forms: { Obj,int,long,double } 
> x { reduce forms }.  Plus the combination of map, reduce, and fused 
> mapReduce leaves users wondering when they should do which.  All to 
> work around boxing.
>
> This can be further mitigated by specialized fused operations for the 
> most common reductions: sumBy(IntMapper), maxBy(IntMapper), etc. 
> (Price: more overloads, more "when do I use what" confusion.)
>
> So, summary so far: we can mitigate boxing costs by cluttering the API 
> with lots of extra methods.  (But I don't think that gets us all the 
> way.)

But given that the inference algorithm and the lambda conversion 
algorithm don't consider Integer as a boxed int (unlike applicable 
method resolution by example),
we need IntFunction, IntOperator etc.
If we have these specialized function interfaces, having specialized 
stream is not as if we have a choice.
The choice was done long before, when the lambda EG decide how 
inference/lambda conversion works.

Now, I dislike fused operations because it goes against the DRY 
principle, the stream interface should be as simple as possible, so an 
operation should never be a compound of several ones and while the 
pipeline can hardly optimize to transform boxing to primitive operation, 
fuzing operations for performance inside the pipeline implementation is 
easy.
So instead of stream.sumBy(IntMapper), we already have: 
stream.map(IntMapper).sum(). If the pipeline prefer to use fuzed 
operation, it's an implementation detail.

>
>
> 2.  Approachability.  Telling Java developers that the way to add up a 
> bunch of numbers is to first recognize that integers form a monoid is 
> likely to make them feel like the guy in this cartoon:
>
>   http://howfuckedismydatabase.com/nosql/
>
> Reduce is wonderful and powerful and going to confuse the crap out of 
> 80+% of Java developers.  (This was driven home to me dramatically 
> when I went on the road with my "Lambdas for Java" talk and saw blank 
> faces when I got to "reduce", even from relatively sophisticated 
> audiences. It took a lot of tweaking -- and explaining -- to get it to 
> the point where I didn't get a room full of blank stares.)
>
> Simply put: I believe the letters "s-u-m" have to appear prominently 
> in the API.  When people are ready, they can learn to see reduce as a 
> generalization of sum(), but not until they're ready.  Forcing them to 
> learn reduce() prematurely will hurt adoption.  (The sumBy approach 
> above helps here too, again at a cost.)

yes, we need sum.

>
>
> 3.  Numerics.  Adding up doubles is not as simple as reducing with 
> Double::sum (unless you don't care about accuracy.)  Having methods 
> for numeric sums gives us a place to put such intelligence; general 
> reduce does not.

I'm always afraid when someone try to put "intelligence" in a program. 
We never have the same.

>
>
> 4.  "Primitives all the way down".  While fused+specialized methods 
> will mitigate many of the above, it only helps at the very end of the 
> chain.  It doesn't help things farther up, where we often just want to 
> generate streams of integers and operate on them as integers.  Like:
>
>   intRange(0, 100).map(...).filter(...).sorted().forEach(...)
>
> or
>
>   integers().map(x -> x*x).limit(100).sum()
>
>
>
> We've currently got a (mostly) complete implementation of integer 
> streams.  The actual operation implementations are surprisingly thin, 
> and many can share significant code across stream types (e.g., there's 
> one implementation of MatchOp, with relatively small adapters for 
> Of{Reference,Int,..}).  Where most of the code bloat is is in the 
> internal supporting classes (such as the internal Node classes we use 
> to build conc trees) and the spillover into public interfaces 
> (PrimitiveIterator.Of{Int,Long,Double}).

Correctly if i'm wrong but PrimitiveIterator are just here because of 
the escape hatch, it's a huge cost for something that will not be used 
very often.
I'm not sure we should provide these public interface and see if you can 
not do better for Java 9.

>
> Historically we've shied away from giving users useful tools for 
> operating on primitives because we were afraid of the combinatorial 
> explosion: IntList, IntArrayList, DoubleSortedSynchronizedTreeList, 
> etc.  While the explosion exists with streams too, we've managed to 
> limit it to something that is tolerable, and can finally give users 
> some useful tools for working with numeric calculations.
>
>
> We've already limited the explosion to just doing int/long/double 
> instead of the full eight.  We could pare further to just long/double, 
> since ints can fit easily into longs and most processors are 64-bit at 
> this point anyway.
>

processor are 64bits but using ints is still faster than long because 
there is less bus traffic.

Rémi