Dear all,
in today's R Core meeting both the CRAN team and R Core agree with
Simon's suggestion below.
Let me repeat the key points:
- We will try to add some interface to R that allows for more unified
control about the various ways of parallelisation. That should allow
users to opt in for
Tim,
I think that things like data.table have a different set of problems
depending on the environment. Working out what the right degree of
parallelism for an IO workload is is a hard question that depends on the
characteristics of the IO subsystem, the characteristics of the dataset and
on what
I’m definitely sympathetic to both sides but have come around to the view of
Greg, Dirk et al. It seems sensible to have a default that benefits the
majority of “normal” users and require explicit action in shared environments
not vice-versa.
That is not to say that data.table could not do bett
The question should be, in how many cases is the current behaviour a
problem? In a shared environment, sure, you have to be more careful. I'd
say don't let the teenagers in there. The CRAN build server does need to do
something to protect itself and I don't greatly mind the 2 thread limit, I
impl
On 25 August 2023 at 18:48, Jeff Newmiller wrote:
| You have a really bizarre way of twisting what others are saying, Dirk. I
have seen no-one here saying 'limit R to 2 threads' except for you, as a way to
paint opposing views to be absurd.
That's too cute.
Nobody needs to repeat it, and some
You have a really bizarre way of twisting what others are saying, Dirk. I have
seen no-one here saying 'limit R to 2 threads' except for you, as a way to
paint opposing views to be absurd.
What _is_ being said is that users need to be in control_, but _the default
needs to do least harm_ until
On 26 August 2023 at 12:05, Simon Urbanek wrote:
| In reality it's more people running R on their laptops vs the rest of the
world.
My point was that we also have 'single user on really Yuge workstation'.
Plus we all know that those users are often not sysadmins, and do not have
our levels of
> On Aug 26, 2023, at 11:01 AM, Dirk Eddelbuettel wrote:
>
>
> On 25 August 2023 at 18:45, Duncan Murdoch wrote:
> | The real problem is that there are two stubborn groups opposing each
> | other: the data.table developers and the CRAN maintainers. The former
> | think users should by def
Sanity seems to be in the eye of the beholder. FWIW I am certainly not CRAN or
R Core, but I pretty strongly disagree with any package that defaults to using
more than 2 cores. If I am using a shared HPC I can get in trouble if I
over-consume cpu resources ... i.e. I may be given access to 10 co
On 25 August 2023 at 18:45, Duncan Murdoch wrote:
| The real problem is that there are two stubborn groups opposing each
| other: the data.table developers and the CRAN maintainers. The former
| think users should by default dedicate their whole machine to
| data.table. The latter think use
To be fair, data.table defaults to using 1/2 the available cores; they do not
take the entire machine by default.
Avi
Sent from my iPhone
> On Aug 25, 2023, at 6:46 PM, Duncan Murdoch wrote:
>
> On 25/08/2023 6:13 p.m., Toby Hocking wrote:
>> Thanks Dirk. I agree.
>> data.table is not in a
I've been lurking on this discussion and have a question.
What does data.table do to pass CRAN tests? If this is a problem for
packages that use data.table, then it certainly is a problem for data.table
itself.
On Fri, Aug 25, 2023 at 3:46 PM Duncan Murdoch
wrote:
> On 25/08/2023 6:13 p.m., Tob
On 25/08/2023 6:13 p.m., Toby Hocking wrote:
Thanks Dirk. I agree.
data.table is not in a situation to update very soon, so the easiest
solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
to 2 on the Windows and Debian machines doing this test.
Otherwise the 1400+ packages with
Thanks Dirk. I agree.
data.table is not in a situation to update very soon, so the easiest
solution for the R community would be for CRAN to set OMP_THREAD_LIMIT
to 2 on the Windows and Debian machines doing this test.
Otherwise the 1400+ packages with hard dependencies on data.table will
each have
On 24 August 2023 at 07:42, Fred Viole wrote:
| Hi, I am receiving a NOTE upon submission regarding the re-building of
| vignettes for CPU time for the Debian check.
|
| I am unable to find any documented instances or solutions to this issue.
| The vignettes currently build in 1m 54.3s locally a
* checking re-building of vignette outputs ... [577s/63s] NOTE
Re-building vignettes had CPU time 9.2 times elapsed time
--> Do not use more than 2 cores
Best,
Uwe Ligges
On 24.08.2023 13:42, Fred Viole wrote:
Hi, I am receiving a NOTE upon submission regarding the re-building of
vignettes
Hi, I am receiving a NOTE upon submission regarding the re-building of
vignettes for CPU time for the Debian check.
I am unable to find any documented instances or solutions to this issue.
The vignettes currently build in 1m 54.3s locally and in 56s on the Win
check.
https://win-builder.r-project
17 matches
Mail list logo
