[concurrency-interest] A beginner question (on fork-and-join)
kav at it.edu
Mon Nov 21 17:42:01 EST 2011
It looks like you aren't doing any real CPU work.
So you are most likely just thrashing the memory system.
That is all threads are spending most of the time just waiting for
Try doing some mindless calculations on each element.
I am pretty sure you will see the parallel version come out as a winner.
On Mon, Nov 21, 2011 at 22:15, David Harrigan <dharrigan at gmail.com> wrote:
> Hi Everyone,
> I'm learning about the fork and join framework in JDK7 and to test it
> out I wrote a little program that tries to find a number at the end of
> a list with 50,000 elements.
> What puzzles me is when I run the "find" in a sequential fashion, it
> returns faster than if I use a fork-and-join implementation. I'm
> running each "find" 5000 times
> so as to "warm" up the JVM. I've got a timing listed below:
> Generating some data...done!
> Simon Stopwatch: total 1015 s, counter 5000, max 292 ms, min 195 ms,
> mean 203 ms [sequential INHERIT]
> Simon Stopwatch: total 1352 s, counter 5000, max 4.70 s, min 243 ms,
> mean 270 ms [parallel INHERIT]
> (some runtime information)
> openjdk version "1.7.0-ea"
> OpenJDK Runtime Environment (build 1.7.0-ea-b215)
> OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)
> 2.66Mhz Intel Core i7 with 8GB RAM (256KB L2 cache per core (4 cores)
> and 4MB L3 cache) running on a MBP (Lion 10.7.2)
> Forgive my ignorance but this type of programming is still quite new
> to me and I'm obviously doing something wrong, but I don't know what.
> My suspicion is
> something to do with spinning up and down threads and the overhead
> that entails. I've posted the src here http://pastebin.com/p96R24R0.
> My sincere apologies if this list is not appropriate for this posting,
> if so I would welcome a pointer on where I can find more information
> to help me understand
> better the behaviour of my program when using F&J.
> I thought that by using F&J I would be able to find the answer quicker
> than doing the searching sequentially, perhaps I've choosen a wrong
> initial problem to
> test this out (something that is suited to a sequential search and not
> a parallel search?)
> Thank you all in advance.
> I prefer encrypted and signed messages. KeyID: B20A22F9
> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
> "It is not usually until you've built and used a version of the
> program that you understand the issues well enough to get the design
> right." - Rob Pike, Brian Kernighan.
> No trees were harmed in the sending of this message, however, a number
> of electrons were inconvenienced.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest