Primitive streams

[Brian Goetz]

Summary: Remi says:

  - Yes, unfortunately we need primitive streams
  - Given primitive streams, fused ops are just extra complexity
  - Dropping IntStream (simulating with LongStream, as we do for short, 
byte, and char) is a questionable economy

Other opinions?

On 12/29/2012 1:00 PM, Remi Forax wrote:
> 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
>