Hi Paul And Everyone
Sorry for getting back late.
I took Paul's suggestion and have written other two demos which presents
usage of parallel computation. One is using Monte-Carlo to calculate
value of PI. Other is find a big prime by given length. Please review it.
http://cr.openjdk.java.net/~tyan/sample/webrev.00/
<http://cr.openjdk.java.net/%7Etyan/sample/webrev.00/>
There is another demo which present mandelbrot set was designed
Alexander Kouznetsov has been already in reviewing. It's not my code
review request.
Thank you very much
Tristan
On 10/15/2013 11:20 PM, Paul Sandoz wrote:
On Oct 15, 2013, at 4:35 PM, Tristan Yan <tristan....@oracle.com
<mailto:tristan....@oracle.com>> wrote:
Hi Paul
you have comments "suggest that all streams are sequential. There is
an inconsistency in the use and in some cases it is embedded in other
stream usages."
We do not really understand what exactly is meant, could you
elaborate a little bit. Is it because we want to show ppl that we
should use stream more than parallelStream?
Going parallel is easy to do but not always the right thing to do.
Going parallel almost always requires more work with the expectation
that work will complete sooner than the work required to get the same
result sequentially. There are a number of factors that affect whether
parallel is faster than sequential. Two of those factors are N, the
size of the data, and Q the cost of processing an element in the
pipeline. N * Q is a simple cost model, the large that product the
better the chances of parallel speed up. N is easy to know, Q not so
easy but can often be intuitively guessed. (Note that there are other
factors such as the properties of the stream source and operations
that Brian and I talked about in our J1 presentation.)
Demo code that just makes everything (or most streams) parallel is
sending out the wrong message.
So i think the demo code should present two general things:
1) various stream functionality, as you have done;
2) parallel vs. sequential for various cases where it is known that
parallel is faster on a multi-core system.
For 2) i strongly recommend measuring using jmh [1]. The data sets you
have may or may not be amenable to parallel processing, it's worth
investigating though.
I have ideas for other parallel demos. One is creating probably primes
(now that SecureRandom is replaced with ThreadLocalRandom), creating a
probably prime that is a BigInteger is an relatively expensive
operation so Q should be high. Another more advanced demo is a
Monte-Carlo calculation of PI using SplittableRandom and a special
Spliterator, in this case N should be largish. But there are other
simpler demonstrations like sum of squares etc to get across that N
should be large. Another demo could be calculation of a mandelbrot
set, which is embarrassingly parallel over an area in the complex plane.
So while you should try and fit some parallel vs. sequential execution
into your existing demos i do think it worth having a separate set of
demos that get across the the simple cost model of N * Q. So feel free
to use some of those ideas previously mentioned, i find those ideas
fun so perhaps others will too :-)
Paul.
[1] http://openjdk.java.net/projects/code-tools/jmh/
On Oct 15, 2013, at 4:37 PM, Tristan Yan <tristan....@oracle.com
<mailto:tristan....@oracle.com>> wrote:
Also there is one more question I missed
You suggested ""ParallelCore" is not a very descriptive name. Suggest
"streams"."
1) yes we agree this demo is not for parallel computation per se
2) but we do not have a clear demo for parallel computation
3) if we are to rename this, we need to develop another one, do you
have a scenario for that?
