[concurrency-interest] help show speed-up on a trivial but manual array-map operation?

Dan Grossman djg at cs.washington.edu
Sun Mar 25 16:48:10 EDT 2012

Just to close the loop on this thread, today I edited


which is part of the materials at


I added a new section "timing issues" that lists various reasons why
you might see a /simple/ fork-join computation run slower than a
corresponding sequential implementation.  This distills the
suggestions on this thread and other well-known ideas.  Additional
suggestions and clarifications are welcome.


On Fri, Mar 9, 2012 at 6:40 PM, Dan Grossman <djg at cs.washington.edu> wrote:
> Let me echo Kim's word of thanks.
> When I have time in a couple weeks, I hope to extend my materials to
> include some of the excellent points and example made here: gotchas
> with respect to timing, the need for large enough problem sizes, and
> -- most important in my mind -- the need for beefy enough arithmetic
> operations to overcome memory-bandwidth issues.
> As Kim points out, any simple-enough-for-undergraduate-lecture
> examples are welcome.
> --Dan
> On Fri, Mar 9, 2012 at 5:47 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
>> Thanks to Doug and everyone else for their suggestions.  Doug's changes seem to buy me about a 12 times speed-up with a 48 core machine.  This will definitely be more impressive for my students than the slowdowns or marginal speed-ups we were getting before.
>> I'd be thrilled to see a set of relatively simple (to explain) programs using ForkJoin that could be used to demonstrate significant speedups with many-core computers.  I'm going to be asking students to do some timing in a lab in a couple of weeks and would like them to be able to do things that do show significant speedup.
>> Also valuable would be pointers to sites that might have good parallel/concurrency class projects (especially week-long assignments) for students in a data structures course learning about how to use these constructs.
>> Thanks again for everyone's help!
>> Kim
>> On Mar 9, 2012, at 5:20 AM, Doug Lea wrote:
>>> On 03/09/12 08:11, Doug Lea wrote:
>>>> 1. Microbenchmarking artifacts: The results of the
>>>> computations are never used so JVMs can kill some of the
>>>> code. The attached edited version includes a "checkSum" method
>>>> that combats this.
>>> Plus, as I should have checked before, the use of a linear
>>> stream of initial values is also subject to microbenchmarking
>>> artifacts. Filling with random values instead combats this.
>>> The main moral is that reliably measuring anything on modern
>>> systems is harder than you'd think it should be.
>>> -Doug
>>> <VecAdd.java>

More information about the Concurrency-interest mailing list