[R-SIG-Mac] [R-sig-hpc] Grand Central Dispatch (simple loop optimization)

[Simon Urbanek]

On Sep 17, 2009, at 15:20 , Simon Urbanek wrote:

> Jan,
>
> thanks for sharing this. This is really interesting. We have been  
> contemplating using GCD for R (mainly pnmath) but at the time OMP  
> was faster. However, GCD got apparently really good in the meantime:
>
> > system.time(threads(100000,1000,"omp_try"))
>   user  system elapsed
>  9.671   0.009   2.441
> > system.time(threads(100000,1000,"gcd_try"))
>   user  system elapsed
>  9.592   0.004   2.410
> > system.time(threads(100000,1000,"dcg_try"))
>   user  system elapsed
>  9.784   0.003   9.788
>
> [This is on Harpertown 2.66GHz quad core]
>
> So GCD is surprisingly just a hair faster than OMP (also surprising  
> to me is that using more threads than cores make OMP faster - the  
> above is with 16 threads).
>

Actually, with schedule(dynamic) the gap is almost at the level of the  
measurement error:

 > system.time(threads(100000,1000,"omp_try"))
    user  system elapsed
   9.614   0.006   2.420
 > system.time(threads(100000,1000,"gcd_try"))
    user  system elapsed
   9.586   0.005   2.409

-- the OMP line (to be placed before the for() loop) is 
#pragma omp parallel for default(shared) private(i) schedule(dynamic)

Cheers,
Simon


>
> On Sep 17, 2009, at 14:24 , Jan de Leeuw wrote:
>
>> a) Obviously OpenMP is more portable. Even on a Mac I had to use  
>> Apple's gcc in this case
>>  (I normally use the GNU gcc-trunk).
>>
>> b) GCD does not require specifying the number of threads -- it  
>> determines it at runtime.
>>
>> c) Coding is simpler.
>>
>
> I would not say - OMP takes just one #pragma - no need to change  
> your code whereas GCD requires several special function calls...  
> However, OMP is more limited in the kind of things you can do.
>
> Cheers,
> Simon
>
>
>> d) Since GCD is at a lower OS level than OpenMP, it will probably  
>> handle resource allocation
>>  better. But my small example, on an otherwise idle Mac Pro (16  
>> cores, 32 GB of RAM), does
>>  not really highlight that.
>>
>> e) For more info, and some OpenMP comparisons, see
>>
>>  http://www.macresearch.org/cocoa-scientists-xxxi-all-aboard-grand-central
>>  http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
>>
>> To quote Syracuse
>>
>> "Write your application as usual, but if there's any part of its  
>> operation that can
>> reasonably be expected to take more than a few seconds to complete,  
>> then for the love of Zarzycki,
>> get it off the main thread!"
>>
>> On Sep 17, 2009, at 11:03 , Saptarshi Guha wrote:
>>
>>> Nice, how does this compare when using OpenMP?
>>> How does it compare when several other core hungry processes are  
>>> running?( GC is supposed to nicely handle resource allocation,  
>>> does OpenMP compete with the other processes?).
>>>
>>> Regards
>>> Saptarshi
>>>
>>>
>>
>> ===
>> Jan de Leeuw; Distinguished Professor and Chair, UCLA Department of  
>> Statistics;
>> Director: UCLA Center for Environmental Statistics (CES);
>> Editor: Journal of Multivariate Analysis, Journal of Statistical  
>> Software;
>> US mail: 8125 Math Sciences Bldg, Box 951554, Los Angeles, CA  
>> 90095-1554
>> phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw at stat.ucla.edu
>> .mac: jdeleeuw ++++++  aim: deleeuwjan ++++++ skype: j_deleeuw
>> homepages: http://gifi.stat.ucla.edu ++++++ http:// 
>> www.cuddyvalley.org
>> -------------------------------------------------------------------------------------------------
>>         No matter where you go, there you are. --- Buckaroo Banzai
>>                  http://gifi.stat.ucla.edu/sounds/nomatter.au
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>>
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>