[Rd] parallel::mclapply() dummy function on Windows?
mtmorgan at fhcrc.org
Sat Oct 8 14:15:41 CEST 2011
On 10/07/2011 06:03 PM, John Fox wrote:
> Dear Tim,
>> -----Original Message-----
>> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org]
>> Behalf Of Tim Triche, Jr.
>> Sent: October-07-11 3:05 PM
>> To: Prof Brian Ripley
>> Cc: r-devel
>> Subject: Re: [Rd] parallel::mclapply() dummy function on Windows?
>> On Thu, Oct 6, 2011 at 11:25 PM, Prof Brian Ripley
>> <ripley at stats.ox.ac.uk>wrote:
>>> Why would it make it easier? And how could using a dummy for 'most
>>> (who are on Windows) offer them 'good parallel support'?
>> Good point. Most of my users are on unix, because my use of mclapply() is
>> primarily to expedite processing of raw scanner data. Only a handful of
>> users for the packages that call mclapply() are on Windows. Right now, I
>> default to having parallel=FALSE flags all over the place, but I'd prefer
>> the default to be "go as fast as practical in the common case", i.e.,
>> It would have been more accurate for me to say "I would like to
>> by default, without having the methods fail on Windows in the default
>> configuration" than to claim that I want "good parallel support" for
>> When I have tried using the foreach/doMC combination in the past, it has
>> worked out satisfactorily, so I don't know how well I can support Windows
>> users... period.
> Why don't you just apply the approach you initially suggested in your own
> package, defining mclapply() the way you want it?
Hi John et al.,
Individual packages will become littered with ad hoc solutions,
constructed without, for instance, the wisdom and experience of Prof.
Ripley about platforms or environments in which it is appropriate to use
mclapply. For instance, Tim's pseudo-code if (Windows) ... translated as
if (.Platform$OS.type == "windows") doesn't sound like its the correct
test; at least
but probably more. Also, doesn't parallel's name space differ between
platforms, requiring the package author to import(parallel) rather than
the better practice of importFrom(parallel, mclapply) ?
> I hope this helps,
>> Take a look at e.g. package 'boot' to see how to offer alternatives. (A
>>> version that uses 'parallel' is pending on CRAN, or see
>>> x.ac.uk/pub/R/boot_1.3-3.tar.gz>.) Package 'parallel' may in future
>>> offer a higher-level abstraction layer that makes offers such a choice,
>> as the 'boot' code shows, deciding what to send to the workers in a snow-
>> style cluster is not simple.
>> It seems similar to what I do (off topic: why do you use the file
>> '.q' for all of the R/S code files?): pass flags around. I suppose I was
>> just being lazy, but I would love to default to "go as fast as possible"
>> without having Windows users get left out in the cold (unless they add
>> to their function calls).
>> Thank you for your suggestions, I will look into this further.
>> Tim Triche, Jr.
>> USC Biostatistics
>> [[alternative HTML version deleted]]
>> R-devel at r-project.org mailing list
> R-devel at r-project.org mailing list
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Telephone: 206 667-2793
More information about the R-devel