[R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time

Jeff Newmiller jdnewm|| @end|ng |rom dcn@d@v|@@c@@u@
Sat Aug 26 01:28:20 CEST 2023


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 cores out of 128, and I would rather be reading the documentation to figure out how to boost performance on my own time rather than getting kicked out for not playing nice on the sysadmin's schedule.

Data.table can do lots of things to educate users how to or make it easier to reserve more resources, but they cannot argue with my sysadmin for me.

On August 25, 2023 4:01:33 PM PDT, Dirk Eddelbuettel <edd using debian.org> 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 default dedicate their whole machine to 
>| data.table.  The latter think users should opt in to do that.
>
>No, it feels more like it is CRAN versus the rest of the world.
>
>Take but one example, and as I may have mentioned elsewhere, my day job
>consists in providing software so that (to take one recent example)
>bioinformatics specialist can slice huge amounts of genomics data.  When that
>happens on a dedicated (expensive) hardware with dozens of cores, it would be
>wasteful to have an unconditional default of two threads. It would be the end
>of R among serious people, no more, no less. Can you imagine how the internet
>headlines would go: "R defaults to two threads". 
>
>And it is not just data.table as even in the long thread over in its repo we
>have people chiming in using OpenMP in their code (as data.table does but
>which needs a different setter than the data.table thread count).
>
>It is the CRAN servers which (rightly !!) want to impose constraints for when
>packages are tested.  Nobody objects to that.
>
>But some of us wonder if settings these defaults for all R user, all the
>time, unconditional is really the right thing to do.  Anyway, Uwe told me he
>will take it to an internal discussion, so let's hope sanity prevails.
>
>Dirk

-- 
Sent from my phone. Please excuse my brevity.



More information about the R-package-devel mailing list