Message-ID: <6147A91B-0564-4C01-AD01-6C459DE5D8F9@R-project.org>
Date: 2020-04-02T20:48:46Z
From: Simon Urbanek
Subject: OpenMP on CRAN
In-Reply-To: <8C649F71-1D79-4EA4-8FC9-CFD45CBB0300@ed.ac.uk>
Tim,
> On 3/04/2020, at 2:01 AM, BATES Timothy <tim.bates at ed.ac.uk> wrote:
>
> Moving to a compiler that drops support for OpenMP seems a sad choice, especially now we?ve all climbed the learning curve of the non-Apple compiler (the real barrier was lack of a pkg installer and that?s done now).
>
It has caused a lot of issues, it trips people on a daily basis which is just not worth it. Also with Apple's increasingly strict rules about what can be distributed we don't want to be in the business in maintaining a separate toolchain. There have been numerous issues with C++ exceptions so the fall out was much bigger than originally expected and it would only get worse.
> Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would be a big loss for users (for whom the CRAN version now supports OpenMP giving them a 2-12x speed up). In general, R on Mac is made more viable by having OpenMP
>
> Re Brian?s points, I?d say that the distribution problem is crucial: Packages not on CRAN have dramatically diminished accessibility/useage.
>
The idea is that if a package deems this critical, it can enable this for the users. As it is now, packages can still supply iomp and use it.
That said, I would open for discussion the ability to distribute iomp with the R binary, but it would not be supported by R directly, i.e., it would be on the package author to make sure that the way the package operates is compatible with that binary. Let me know what you think.
> Second, a great range of compute-intensive problems are amenable to division amongst cores, including nearly all models that take more than a nominal amount of time to run: So simulations, CIs, bootstrapping, nearly everything in genetics all speeds up.
>
Yes, but OpenMP is rarely used for those tasks. In R OpenMP can be only used for very small subset of such tasks - which is why alternative approaches are much more common.
Cheers,
Simon
> I?d say especially on desktop/laptop. The big advantage of multi blade systems requires snowfall-type solutions, but desktops profit automatically from their multi-core structure and don;?t have multiple processors (except graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP is their one trick. I?d hope not to lose it.
>
> Best, t
>
>
>> On 2 Apr 2020, at 05:18, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
>>
>> On 01/04/2020 22:02, Simon Urbanek wrote:
>>> JJB,
>>> 1. correct, there was too much trouble in this. But please feel free to start a new thread about this here if you have strong opinions.
>>
>> Also note that it is possible (and not hard) to install packages from source with an OpenMP-supporting compiler, and how to do so is in the R-admin manual. The problems come in distributing them.
>>
>> The benefits of OpenMP are often overestimated, especially on desktop/laptop level hardware. But it is available for the small (tiny?) proportion of users who need it.
> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac