Re: [R-SIG-Mac] Can R on a Mac use the GPU

[Taras Zakharko]

Dear Bill, 

I think this warning comes from a time when Apple’s implementation of these 
libraries were severely neglected. From what I understand, this is less of an 
issue today, as Apple has improved their efforts in this domain, even though 
some of the routines are still a bit outdated. And of course, this is still 
closed source, so it is unknown what kind of bugs or accuracy issues are there. 

Then again, using Apple’s Accelerate is pretty much the only way to officially 
access the numerical coprocessor. I’d recommend that you give it a try and 
validate it on some data you already have results for. Could be a nice boost in 
performance that you re looking for, could be a few wasted hours. One never 
knows :)

Best, 

Taras

> On 22 Feb 2023, at 16:54, William R Revelle  wrote:
> 
> Dear Taras et al.
> 
> I currently use 
> 
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib
> 
> In the help page for R-mac developers it says:
> 
> The BLAS library used by R depends on the way R was compiled (see ‘R 
> Installation and Administration’ manual for details). Current R binaries 
> supplied from CRAN provide both vecLib-based BLAS and reference BLAS shipped 
> with R. vecLib is a part of Apple’s Accelerate framework which provides an 
> optimized BLAS implementation for Mac hardware. Although fast, it is not 
> under our control and may possibly deliver inaccurate results.
> 
> The CRAN binary uses --enable-BLAS-shlib option and two Rblas shared 
> libraries are supplied: libRblas.vecLib.dylib which uses vecLib BLAS and 
> libRblas.0.dylib which uses reference BLAS from R. A symbolic link 
> libRblas.dylib determines which one is used. Currently the default is to use 
> the R BLAS: this is recommended for precision.
> 
> The statement: "Although fast, it is not under our control and may possibly 
> deliver inaccurate results” worries me.  Should it?
> 
> My routines that are most matrix heavy are finding correlations, doing factor 
> analysis using my fa function, and using the CFA function in Lavaan.  
> Accuracy in these results is important,
> 
> But spending several hours finding large correlation matrices has driven me 
> to search for speed.
> 
> 
> 
> Bill
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Feb 22, 2023, at 12:46 AM, Taras Zakharko  wrote:
>> 
>> H Bill, 
>> 
>> I am not aware of any packages that do this for you directly. While it is 
>> certainly possible to write a Metal shader that will get the job done, it 
>> will likely take a substantial amount of non-trivial effort. To further 
>> complicate the issue Apple GPUs do not support double-precision computation 
>> (used by R). 
>> 
>> Maybe it would be possible for you to accelerate computation used 
>> Apple-provided routines from the Acceleration framework (e.g. BLAS and 
>> LAPACK)? Many of those routines have access to the hardware matrix 
>> accelerators present on Apple hardware and can result in major performance 
>> improvements. 
>> 
>> Best, 
>> 
>> Taras 
>> 
>>> On 21 Feb 2023, at 18:12, William R Revelle  
>>> wrote:
>>> 
>>> Dear R-Mac users.
>>> 
>>> In trying to speed up a large correlation problem (600K subjects, 6k 
>>> variables,)  which I can do using my bigCor function, I decided it was time 
>>> to learn how to use GPU on my Mac book with its M1 Max gpu.  
>>> 
>>> Having spent a day searching the web and trying  various approaches, I give 
>>> up.
>>> 
>>> Are there any packages I can use to do calculations on the GPU part of my 
>>> Mac using R?
>>> 
>>> Thanks.
>>> 
>>> Bill
>>> 
>>> William Revelle   personality-project.org/revelle.html
>>> Professor  personality-project.org
>>> Department of Psychology www.wcas.northwestern.edu/psych/
>>> Northwestern University   www.northwestern.edu/
>>> Use R for psychology personality-project.org/r
>>> It is 90 seconds to midnight   www.thebulletin.org
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> William Revellepersonality-project.org/revelle.html
> Professor   personality-project.org
> Department of Psychology www.wcas.northwestern.edu/psych/
> Northwestern Universitywww.northwestern.edu/
> Use R for psychology personality-project.org/r
> It is 90 seconds to midnight   www.thebulletin.org
> 
> 
> 
> 
> 
> 
> 


[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Can R on a Mac use the GPU

[Taras Zakharko]

H Bill, 

I am not aware of any packages that do this for you directly. While it is 
certainly possible to write a Metal shader that will get the job done, it will 
likely take a substantial amount of non-trivial effort. To further complicate 
the issue Apple GPUs do not support double-precision computation (used by R). 

Maybe it would be possible for you to accelerate computation used 
Apple-provided routines from the Acceleration framework (e.g. BLAS and LAPACK)? 
Many of those routines have access to the hardware matrix accelerators present 
on Apple hardware and can result in major performance improvements. 

Best, 

Taras 

> On 21 Feb 2023, at 18:12, William R Revelle  wrote:
> 
> Dear R-Mac users.
> 
> In trying to speed up a large correlation problem (600K subjects, 6k 
> variables,)  which I can do using my bigCor function, I decided it was time 
> to learn how to use GPU on my Mac book with its M1 Max gpu.  
> 
> Having spent a day searching the web and trying  various approaches, I give 
> up.
> 
> Are there any packages I can use to do calculations on the GPU part of my Mac 
> using R?
> 
> Thanks.
> 
> Bill
> 
> William Revelle  personality-project.org/revelle.html
> Professor   personality-project.org
> Department of Psychology www.wcas.northwestern.edu/psych/
> Northwestern University  www.northwestern.edu/
> Use R for psychology personality-project.org/r
> It is 90 seconds to midnight   www.thebulletin.org
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] CRAN package checks on M1 Mac

[Taras Zakharko]

Ah, I see, so it’s an XQuartz issue… thanks for clarifying! 

> On 22 Dec 2020, at 10:37, Duncan Murdoch  wrote:
> 
> On 22/12/2020 3:45 a.m., Taras Zakharko wrote:
>> Thanks, this is great!
>> Why do you say that OpenGL is not available though? M1 has a fully working 
>> OpenGL framework implemented on top of Metal. Apple might have deprecated 
>> OpenGL, but I think it’s unlikely they will drop it any time soon seeing 
>> that they went through the effort of updating their OpenGL wrapper to 
>> support desktop GL.
> 
> rgl uses GLX from XQuartz, and from the rgl install log:
> 
> ld: warning: ignoring file /usr/X11/lib/libGL.dylib, missing required 
> architecture arm64 in file /usr/X11/lib/libGL.dylib (2 slices)
> ld: warning: ignoring file /usr/X11/lib/libGLU.dylib, missing required 
> architecture arm64 in file /usr/X11/lib/libGLU.dylib (2 slices)
> ld: warning: ignoring file /usr/X11/lib/libX11.dylib, missing required 
> architecture arm64 in file /usr/X11/lib/libX11.dylib (2 slices)
> 
> and the the dyn.load of rgl.so fails with Symbol not found: _XAllocClassHint.
> 
> But even if this is eventually fixed, these changes make installing rgl a lot 
> easier.
> 
> Duncan Murdoch
> 
> 
>> Best,X
>> Taras
>>> On 21 Dec 2020, at 17:32, Duncan Murdoch  wrote:
>>> 
>>> Along the same lines:  I have been working with Prof Ripley to get rgl to 
>>> work on M1.  Since OpenGL isn't available, it produces only WebGL output 
>>> (viewable using rglwidget()) and can't do snapshots or Postscript output, 
>>> but it should be enough to let its reverse dependencies install.
>>> 
>>> Anyone interested in testing it can install from R-forge or Github:
>>> 
>>> install.packages("rgl", repos="http://R-Forge.R-project.org;, type = 
>>> "source")
>>> 
>>> or
>>> 
>>> remotes::install_github("https://github.com/r-forge/rgl;, subdir = 
>>> "pkg/rgl")
>>> 
>>> To see what it looks like without OpenGL on Windows, try
>>> 
>>> Sys.setenv(RGL_NO_OPENGL = TRUE)
>>> 
>>> before the install, or on a Unix-alike,
>>> 
>>> install.packages("rgl", repos="http://R-Forge.R-project.org;,
>>>  INSTALL_opts = '--configure-args="--disable-opengl"',
>>>  type = "source")
>>> 
>>> Duncan Murdoch
>>> 
>>> 
>>> On 21/12/2020 9:01 a.m., Jeroen Ooms wrote:
>>>> On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley  
>>>> wrote:
>>>>> 
>>>>> We have managed a fairly complete check run with natively-compiled R and
>>>>> packages, and a full one with x86_64 R and packages running under
>>>>> Rosetta (mainly using CRAN binary distributions).
>>>>> 
>>>>> The bottom line is that running under Rosetta works really well.
>>>>> Although relative speeds vary widely, using the native build was
>>>>> 1.3-1.5x faster for the central 50% of the distribution.  And a MacBook
>>>>> Air is remarkably capable for a lightweight laptop.
>>>>> 
>>>>> 
>>>>> x86_64 tests
>>>>> 
>>>>> 
>>>>> I compared the check output to that from my 2012 iMac: typically this
>>>>> was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini
>>>>> about that much faster than mine).
>>>>> 
>>>>> A couple of packages ran much slower than on the iMac and hit their
>>>>> check limits, and one fails because it checks elapsed time (and was
>>>>> slower than on the iMac).
>>>>> 
>>>>> 10 packages segfaulted in their checks (but most of those are known to
>>>>> segfault intermittently on other platforms).
>>>>> 
>>>>> There were issues with packages attempting to work with Python, which
>>>>> may be Big Sur differences.
>>>>> 
>>>>> Given that I have 58 packages failing their checks on the iMac under
>>>>> High Sierra this was a very small amount of degradation.
>>>>> 
>>>>> 
>>>>> native tests
>>>>> 
>>>>> 
>>>>> Currently I have 57 CRAN packages failing to install, but 650 others
>>>>> require those or BioC packages which fail to install (the most commonly
>>>>> required being rgl and 

Re: [R-SIG-Mac] CRAN package checks on M1 Mac

[Taras Zakharko]

Thanks, this is great!

Why do you say that OpenGL is not available though? M1 has a fully working 
OpenGL framework implemented on top of Metal. Apple might have deprecated 
OpenGL, but I think it’s unlikely they will drop it any time soon seeing that 
they went through the effort of updating their OpenGL wrapper to support 
desktop GL. 

Best, 

Taras


> On 21 Dec 2020, at 17:32, Duncan Murdoch  wrote:
> 
> Along the same lines:  I have been working with Prof Ripley to get rgl to 
> work on M1.  Since OpenGL isn't available, it produces only WebGL output 
> (viewable using rglwidget()) and can't do snapshots or Postscript output, but 
> it should be enough to let its reverse dependencies install.
> 
> Anyone interested in testing it can install from R-forge or Github:
> 
> install.packages("rgl", repos="http://R-Forge.R-project.org;, type = "source")
> 
> or
> 
> remotes::install_github("https://github.com/r-forge/rgl;, subdir = "pkg/rgl")
> 
> To see what it looks like without OpenGL on Windows, try
> 
> Sys.setenv(RGL_NO_OPENGL = TRUE)
> 
> before the install, or on a Unix-alike,
> 
> install.packages("rgl", repos="http://R-Forge.R-project.org;,
>  INSTALL_opts = '--configure-args="--disable-opengl"',
>  type = "source")
> 
> Duncan Murdoch
> 
> 
> On 21/12/2020 9:01 a.m., Jeroen Ooms wrote:
>> On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley  
>> wrote:
>>> 
>>> We have managed a fairly complete check run with natively-compiled R and
>>> packages, and a full one with x86_64 R and packages running under
>>> Rosetta (mainly using CRAN binary distributions).
>>> 
>>> The bottom line is that running under Rosetta works really well.
>>> Although relative speeds vary widely, using the native build was
>>> 1.3-1.5x faster for the central 50% of the distribution.  And a MacBook
>>> Air is remarkably capable for a lightweight laptop.
>>> 
>>> 
>>> x86_64 tests
>>> 
>>> 
>>> I compared the check output to that from my 2012 iMac: typically this
>>> was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini
>>> about that much faster than mine).
>>> 
>>> A couple of packages ran much slower than on the iMac and hit their
>>> check limits, and one fails because it checks elapsed time (and was
>>> slower than on the iMac).
>>> 
>>> 10 packages segfaulted in their checks (but most of those are known to
>>> segfault intermittently on other platforms).
>>> 
>>> There were issues with packages attempting to work with Python, which
>>> may be Big Sur differences.
>>> 
>>> Given that I have 58 packages failing their checks on the iMac under
>>> High Sierra this was a very small amount of degradation.
>>> 
>>> 
>>> native tests
>>> 
>>> 
>>> Currently I have 57 CRAN packages failing to install, but 650 others
>>> require those or BioC packages which fail to install (the most commonly
>>> required being rgl and V8 [*]).  And ca 120 packages are not using
>>> conditionally Suggests packages which fail to install.
>>> 
>>> There are segfaults from ca 150 packages using minpack.lm::nls.lm,
>>> deSolve::lsoda, rootSolve::stode ... all of which use Fortran.
>>> 
>>> That platform does not have long doubles nor extended precision but the
>>> CRAN checking on Linux and Sparc with --disable-long-doubles has paid
>>> off: only a handful of check results show numerical differences.
>>> 
>>> Quite a lot of external software and several packages have had to be
>>> patched, and it is early days for the former (and the Fortran compiler)
>>> - for example I was able to build v8, but V8 segfaulted in its checks.
>> Thank you for these fantastic efforts. I have added a binary for
>> libv8, so it works on arm64 now.
>> Re: the more general problem of external software, are there any
>> details available on how the external software on your server was
>> built/configured? For example I don't see libv8 on
>> https://github.com/R-macos/recipes or
>> https://mac.r-project.org/libs-arm/ so this makes it difficult for
>> package authors to debug a problem.
>> FWIW, Homebrew is quickly catching up on M1 support. Many people are
>> contributing patches, and François-Xavier Coudert (the same person who
>> is publishing the gfortran binaries) is publishing the homebrew arm64
>> binaries (aka bottles), hundreds over the past weekend:
>> https://github.com/Homebrew/homebrew-core/commits?author=fxcoudert
>> It is recommended to install homebrew on ARM in /opt/homebrew, and not
>> /usr/local, to prevent binaries from getting mixed up
>> (https://github.com/mikelxc/Workarounds-for-ARM-mac ). Using these
>> standard instructions, I was able to check many R packages that are
>> flagged on CRAN. For example:
>> brew install --build-from-source libgit2
>> Will make it possible to install gert and git2r. And:
>> brew install --build-from-source imagemagick@6
>> Will work for 'magick' and:
>> brew install protobuf
>> For protolite.
>> The main bottlenecks are libraries that 

Re: [R-SIG-Mac] NSButton Message in R.app

[Taras Zakharko]

It seems that there are other projects having the same issue, and if I 
understood correctly the “fix” would be to build it with latest Xcode 12 


For example:

https://github.com/macvim-dev/macvim/issues/1114 


Best, 

Taras

> On 15 Dec 2020, at 03:43, Simon Urbanek  wrote:
> 
> Unfortunately, I don't have a Mac with a touch bar to replicate it, I'll see 
> if there is any other way to test it. The GUI doesn't actually use the touch 
> bar, so it's not clear where that message comes from. It seems like just a 
> benign output from the system - it doesn't really affect any functionality, 
> but if it annoys you, you can disable it until we find out more - see R for 
> Mac FAQ 10.4.
> 
> Cheers,
> Simon
> 
> 
>> On 15/12/2020, at 1:14 PM, Macdonald, Peter  wrote:
>> 
>> We discussed this in r-sig-mac a couple of weeks ago but the thread got 
>> hijacked by unrelated Big Sur issues and I don’t think this problem was ever 
>> resolved.
>> 
>> It seems to be an issue with R GUI and MacBook Pro. It arose with the final 
>> versions of Catalina and continued with Big Sur on my 15 inch 2018 MacBook 
>> Pro. The error is generated whenever the GUI uses the Touch Bar.
>> 
>> The Touch Bar works correctly despite and I’ve seen no other consequences.
>> 
>> I was going to bring this up again, thanks for saving me the trouble!
>> 
>> Hoping that an R GUI developer can fix it?
>> 
>> Thanks,
>> Peter 
>> 
>> --
>> Peter D.M. Macdonald, D.Phil., P.Stat.   
>> Professor Emeritus of Math & Statistics
>> McMaster University
>> Hamilton, Ontario, Canada L8S 4K1
>> 
>> 
>> 
>> 
>>> On Dec 14, 2020, at 6:43 PM, Chacko, George  wrote:
>>> 
>>> Hello all:
>>> 
>>> My apologies if I’m not providing this information in a useful manner, I’m 
>>> new to this list. I’d be happy to revise this message for greater clarity 
>>> with a little advice from the list. After upgrading to Big Sur on a 16 inch 
>>> Macbook Pro, I’ve noticed an NSButton warning message. Reinstalling R 
>>> hasn’t helped. Thanks for any advice. George Chacko
>>> 
>>> 
>>> 1.  when R.app is started up
>>> 
>>> 2020-12-14 09:24:32.330 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or 
>>> equal to 30 but got a height of 32.00. This error will be logged once 
>>> per view in violation.
>>> 
>>> 
>>> 1.  Once R is running, if I use Command-W to exit and then hit cancel, 5 
>>> copies of this message are printed on screen.
>>> 
>>> 2020-12-14 09:25:25.900 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or equal to 30 but got a 
>>> height of 32.00. This error will be logged once per view in violation.
>>> 2020-12-14 09:25:25.904 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or equal to 30 but got a 
>>> height of 32.00. This error will be logged once per view in violation.
>>> 2020-12-14 09:25:25.904 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or equal to 30 but got a 
>>> height of 32.00. This error will be logged once per view in violation.
>>> 2020-12-14 09:25:27.513 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or equal to 30 but got a 
>>> height of 32.00. This error will be logged once per view in violation.
>>> 2020-12-14 09:25:27.516 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or equal to 30 but got a 
>>> height of 32.00. This error will be logged once per view in violation.
>>> 2020-12-14 09:25:27.517 R[30638:726731] Warning: Expected min height of 
>>> view: () to be less than or equal to 30 but got a 
>>> height of 32.00. This error will be logged once per view in violation.
>>> 
>>> 
>>> 
>>> 
 utils::sessionInfo()
>>> R version 4.0.3 (2020-10-10)
>>> Platform: x86_64-apple-darwin17.0 (64-bit)
>>> Running under: macOS Big Sur 10.16
>>> 
>>> Matrix products: default
>>> BLAS:   
>>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
>>> LAPACK: 
>>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>>> 
>>> locale:
>>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.0.3
>>> 
>>> 
>>> Model Name:  MacBook Pro
>>> 
>>> Model Identifier:   MacBookPro16,1
>>> 
>>> Processor Name: 8-Core Intel Core i9
>>> 
>>> Processor Speed:2.3 GHz
>>> 
>>> Number of Processors:1
>>> 
>>> Total Number of Cores:   8
>>> 
>>> L2 Cache (per Core):256 KB
>>> 
>>> L3 Cache: 16 MB
>>> 
>>> Hyper-Threading Technology:Enabled
>>> 
>>> Memory:

Re: [R-SIG-Mac] Apple Silicon aka M1 Macs

[Taras Zakharko]

Creating a native Aarch64 build of R on my M1 machine was surprisingly 
straightforward. Here is a step-by-step instruction of what I did in case 
someone wants to replicate it:

1. Install native homebrew as described in this blog post under “Multiple 
Homebrews” (https://soffes.blog/homebrew-on-apple-silicon). You will need to 
manually chown a bunch of directories, keep an eye on brew output

2. Install the following brew packages

  brew install jpeg libpng libtiff pcre2 pkg-config tcl-tk xz zlib

  Again, pay attention to brew output, it is possible that you will have to 
manually reset ownership on some directories

3. Make sure that zlib can be discovered by pkg-config by making it’s pc file 
discoverable

 ln -s /opt/homebrew/Cellar/zlib/1.2.11/lib/pkgconfig/zlib.pc 
/opt/homebrew/lib/pkgconfig/

4. Install patched gfortran, I used the precompiled package from here: 

 https://github.com/fxcoudert/gfortran-for-macOS/releases/tag/11-arm-alpha1

5. In  config.site, add the paths to homebrew libraries:

 CPPFLAGS=-I/opt/homebrew/include
 LDFLAGS=-L/opt/homebrew/lib

Note: the R-admin manual tells to set CC, CXX, FC in config.sites, but it’s not 
strictly necessary, the build will work without them

5. Run the configure script, I used

  ./configure --enable-R-shlib --without-x  --enable-memory-profiling 
--with-blas="-framework Accelerate”

  Check that the summary makes sense. If PNG is disabled, it’s probably because 
you forgot step 3

6. Build R

  make -j4

7. Check that everything runs

  bin/R

   You should see something like "Platform: arm-apple-darwin20.2.0 (64-bit)” in 
the startup message. 
  
All core tests seems to pass and the performance is excellent. 

I have tried building tidyverse and it blocked on testthat. It seems that 
testthat uses a fairly old version of Catch which doesn’t detect platform 
correctly and tries to use some x86 inline assembly during the arm build… 


> On 23 Nov 2020, at 11:14, Prof Brian Ripley  wrote:
> 
> As a follow-up, I now have a preliminary native build of R (using a gfortran 
> compiled from sources forked from GCC and using minor modifications of Tomas 
> Kalibera's instructions).
> 
> The check timing was 148s, with Aqua (not X11) Tcl/Tk built from the sources 
> and no X11 support, so not quite 100% comparable.
> 
> Building the compiler took 45m elapsed with 100% CPU most of the time: the 
> machine (which has no fan) remained cool (unlike my MBP which has a fan but 
> rarely runs it and does get warm to the touch).
> 
> There is a preliminary write-up on 'arm64' Macs in R-devel's R-admin manual 
> (the version on CRAN is as usual a few days behind).
> 
> On 17/11/2020 14:57, Prof Brian Ripley wrote:
>> Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.
>> For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the 
>> installation with
>> pdf("tests.pdf") ## optional, but prevents flashing graphics windows
>> Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
>> tools::testInstalledBasic("both")
>> tools::testInstalledPackages(scope = "base")
>> tools::testInstalledPackages(scope = "recommended")
>> That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz 
>> i5): happily nothing untoward was reported (some recommended packages give 
>> differences from reference output on both systems).
>> You need to install XQuartz to provide the X11() devices and support for 
>> package Tcl/Tk: everything I tried using that worked as expected.
>> Having done that post-installation check I would happily use the Intel R on 
>> an M1 machine.
>> We plan to check many of the Intel-compiled packages under Rosetta.
>> There are many hours of work ahead to build/test a native toolchain: our 
>> goal is to have a native distribution for R 4.1.0 ca April 2021.
> 
> 
> -- 
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Apple Silicon aka M1 Macs

[Taras Zakharko]

Thank you for this update! I think that Apple Silicon has great potential for 
data science, the SPEC benchmarks reported by Anandtech look very encouraging. 

My M1 Mac should be arriving shortly, is there some way one could help out with 
the effort? 

— Taras

> On 17 Nov 2020, at 15:57, Prof Brian Ripley  wrote:
> 
> Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.
> 
> For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the 
> installation with
> 
> pdf("tests.pdf") ## optional, but prevents flashing graphics windows
> Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
> tools::testInstalledBasic("both")
> tools::testInstalledPackages(scope = "base")
> tools::testInstalledPackages(scope = "recommended")
> 
> That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz i5): 
> happily nothing untoward was reported (some recommended packages give 
> differences from reference output on both systems).
> 
> You need to install XQuartz to provide the X11() devices and support for 
> package Tcl/Tk: everything I tried using that worked as expected.
> 
> Having done that post-installation check I would happily use the Intel R on 
> an M1 machine.
> 
> We plan to check many of the Intel-compiled packages under Rosetta.
> 
> There are many hours of work ahead to build/test a native toolchain: our goal 
> is to have a native distribution for R 4.1.0 ca April 2021.
> 
> -- 
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Bug: R-gui triggers dedicated GPU

[Taras Zakharko]

Dear all, 

the recent versions of R-gui trigger the usage of the dedicated GPU, which 
unnecessarily drains the battery. The fix is very simple: set the
NSSupportsAutomaticGraphicsSwitching to true in the Info.plist. Also: 
https://developer.apple.com/library/content/qa/qa1734/_index.html 
<https://developer.apple.com/library/content/qa/qa1734/_index.html>

Would be nice if this got fixed in a future release! 

Best, Taras


Taras Zakharko

taras.zakha...@uzh.ch
IT Officer/Software Development
-
Department of Comparative Linguistics
University of Zurich 
Plattenstrasse 54, CH-8032 Zurich


[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac