Jan,
On Sep 17, 2009, at 16:16 , Jan de Leeuw wrote:
> on my system (2 x 2.93 quad core Nehalem
> with hyper-threading, so 16 threads max, 16GB RAM,
> 10.6.1, 64bit kernel, 64bit R)
>
> > system.time(threads(100000,1000,"omp"))
> user system elapsed
> 10.249 0.009 0.662
> > system.time(threads(100000,1000,"gcd"))
> user system elapsed
> 10.208 0.008 0.668
> > system.time(threads(100000,1000,"dcg"))
> user system elapsed
> 8.731 0.005 8.738
>
> so omp == gcd, but for more complicated tasks the
> tighter integration may favor gcd
>
> comparing harpertown and nehalem --> surprising
> difference (kernel ? hyper-threading ?)
>
Interesting but consistent with my observations so far - Nehalems are
not any faster than equally clocked Harpertowns (see dcg time). The
only gains are in HT as seen in your example - my Harpertown has 4
logical cpus, yours has 16. My 2.26GHz Nehalem is running Leopard
(because it's the build machine ;)) but the results are similar:
> system.time(threads(100000,1000,"omp_try"))
user system elapsed
12.924 0.031 0.852
> system.time(threads(100000,1000,"dcg_try"))
user system elapsed
11.595 0.009 11.608
Again, the sequential time is about the same as on equally clocked
Harpertown, but the HT helps with a factor of over 13. That explains
where the alleged performance boost on Nehalems comes from ...
It would be interesting to run OMP pnmath with schedule(dynamic) on a
8-core Nehalem and compare that with a stock R ... (pnmath will need a
bit of tweaking because it attempts to be too smart on the number of
threads). Clearly, on many short operations it may cause a hit, but
the gain on long vectors is up to 16 which is impressive ...
Cheers,
Simon
> i have no idea how the open-sourced gcd works on
> non-mac hardware
>
> code is downloadable using webdav from
> public.me.com/jdeleeuw/software/threads
> or using afp://gifi.stat.ucla.edu from
> the deleeuw public directory
>
>
> On Sep 17, 2009, at 12:35 , Simon Urbanek wrote:
>
>> 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
>>>
>>>
>>
>>
>
> ===
> 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
> -------------------------------------------------------------------------------------------------
>
>
>
>
>
>