On May 17, 2013, at 4:45 PM, David Chase <david.r.ch...@oracle.com> wrote:
> > On 2013-05-17, at 10:07 AM, Paul Sandoz <paul.san...@oracle.com> wrote: >>> Baking it in as a static decision is just kicking the can down the road -- >>> once some module that computes CRCs as part of its larger work chooses >>> serial or parallel, what then, if that module's client doesn't like that >>> decision? >>> >> >> Right. i.e. it's not the responsibility of solely the JDK to make the >> decision. > > I don't think I explained my point well enough. There are two ways that this > choice can not be the JDK's decision. The choice can be made as a system > property setting, externally. Or the choice can be made by the programmer, > when they choose, statically and for all uses of their code, to run either in > serial or parallel. > > Suppose we decide that it is a static choice. If I write some package of > intermediate size that performs sorts and CRCs and perhaps BigInteger > arithmetic, I must choose. If I choose serial, it never runs faster, if I > choose parallel, then my clients may discover that my choice causes problems > for them, and they need to set the system property anyway. > > That is, turning the parallelism option into a static choice of method name > is not a good way to go; it only works for programming in the small, and in > general does not remove the need for the system-properties knob. I agree it does not obviate the need for an external controlling mechanism. The static approach also signals programmer intent. Note that for the Stream API there are further reasons for the explicitness (switching from sequential to parallel is not always transparent in terms of the results produced). > We get all the burdens of extra interfaces, but little win, maybe even a net > loss in larger and more complex systems. The default should be parallel, the > default parallel settings should be somewhat conservative but not fully > serial, and people will tune if it is necessary. > I disagree the default should be parallel (conservative or otherwise) since it can change the usage of compute resources from one release to the next, perhaps in ways that are unpredictable and hard to figure out why. That is arguably distributive for a new platform release and even more so for an update release of 7. Paul.
