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. 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. David
