[concurrency-interest] Some interesting (confusing?) benchmark results

thurston at nomagicsoftware.com thurston at nomagicsoftware.com
Tue Feb 12 14:20:04 EST 2013


Here is all of the relevant code in a single blob.  I think it's 
selef-explanatory; sample test is at the end.

http://pastebin.com/WrfBHYSG



On 2013-02-12 01:55, thurston at nomagicsoftware.com wrote:
> Yes, I will push the code and my measurements some time this week.
> I'm really interested in seeing what others' results would be.  What 
> I
> can say is that the timings are surprisingly stable (range 30-40ms)
> and the input data is randomly generated for each test run which can
> certainly affect merge(int[], int[])'s performance
>
> On 2013-02-12 01:50, Kirk Pepperdine wrote:
>> Hi,
>> On 2013-02-11, at 9:52 PM, thurston at nomagicsoftware.com wrote:
>> Hi T,
>>
>> Can you pub the raw data from your runs? Average tends to hide
>> effects and it's difficult to say anything with only that measure.
>>
>> Regards,
>> Kirk
>>
>>
>>> Hello,
>>>
>>> I made some initial attempts at using ForkJoin framework for some 
>>> rather obvious recursively parallel use-cases, namely summing the 
>>> elements of an int[] and also sorting an int[] (randomly filled).
>>>
>>> The problem-sizes I used ranged from 1M - 10M.
>>>
>>> I really enjoy using the framework and find it relatively easy to 
>>> reason about my programs (if not necessarily the internals of the 
>>> framework).
>>> But I was disappointed with the results: in both cases they were 
>>> slower than the corresponding Java serial implementation.
>>>
>>> I completely understand the principle of YMMV, and I wasn't 
>>> expecting 2x speedup, but especially in the case of the sort, but I 
>>> was expecting that ForkJoin would do at least a little better than 
>>> the single-threaded version.  I guess what I'm asking is: are these 
>>> results surprising?  Does it mean I'm doing something wrong?
>>>
>>> I'll give a brief description of my implementation:
>>> single-threaded:  Arrays.sort(int[])
>>>
>>> ForkJoin: I'm using a merge-sort, with THRESHOLD = 250 (arrived at 
>>> by trial-and-error)
>>>
>>> int[] compute()
>>> {
>>> if int[].length < THRESHOLD
>>>    return insertionSort(int[])
>>> left = new MergeSort(int[] //split in half)
>>> right = new MergeSort(int[] //other half)
>>> return merge(right.compute(), left.join())
>>> }
>>>
>>> The insertionSort() and merge() methods are just standard 
>>> implementations; there is a bit of apples to oranges comparison since 
>>> Arrays.sort() uses an optimized quicksort, but we're still talking 
>>> O(nlog(n))
>>>
>>> Just ran it on my laptop:
>>> Windows 7 64-bit
>>> 1.7.0_03; Java HotSpot(TM) 64-Bit Server VM 22.1-b02
>>> Core 2 Duo==> 2 cores 2GHz
>>>
>>> 2M int[]:
>>> single-threaded: ~330ms
>>> ForkJoin (2 workers): ~390ms
>>>
>>> Would appreciate any feedback and hopefully the #s are somewhat 
>>> helpful (and please no scoffawing at my antiquated machine)
>>>
>>> -T
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list