Re: [Rd] OpenBLAS in everyday R?

[Keith O'Hara]

I won’t play nicely with a package that combines omp pragmas with calls to BLAS 
routines, e.g. something you might get with source Armadillo/Eigen/Blaze code, 
for reasons that Benjamin mentioned in his initial email (pthreads vs omp).

Keith

> On Jan 10, 2018, at 1:28 AM, Avraham Adler  wrote:
> 
> On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara  wrote:
>> 
>> Check if libopenblas is linked against libomp or libgomp.
>> 
>> I’d be curious to see any errors that arise when an OpenMP version of 
>> OpenBLAS is linked with R.
>> 
>> Keith
>> 
> 
> The one time I tried compiling OpenBLAS for Windows 64 with USE OMP =
> 1, I got an error. I don't recall if it was in the compilation of R or
> in use. Regardless, I compile OpenBLAS without setting that flag and
> it still plays nicely with all R packages, including those that use
> OpenMP.
> 
> Avi

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R CMD build then check fails on R-devel due to serialization version

[Neal Richardson]

Hi,
Since yesterday I'm seeing `R CMD check --as-cran` failures on the
R-devel daily build (specifically, R Under development (unstable)
(2018-01-09 r74100)) for multiple packages:

* checking serialized R objects in the sources ... WARNING
Found file(s) with version 3 serialization:
‘build/vignette.rds’
Such files are only readable in R >= 3.5.0.
Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version =
2) as appropriate

As far as I can tell, revision 74099
(https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97),
which changes the default serialization format to 3, clashes with
revision 73973 
(https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00),
which checks that serialized R objects are _not_ version 3. It seems
that with the current development version of R, if you `R CMD build`
and then run `R CMD check --as-cran` on the built package, it will
fail.

Neal

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD build then check fails on R-devel due to serialization version

[Duncan Murdoch]

On 10/01/2018 1:26 PM, Neal Richardson wrote:

Hi,
Since yesterday I'm seeing `R CMD check --as-cran` failures on the
R-devel daily build (specifically, R Under development (unstable)
(2018-01-09 r74100)) for multiple packages:

* checking serialized R objects in the sources ... WARNING
Found file(s) with version 3 serialization:
‘build/vignette.rds’
Such files are only readable in R >= 3.5.0.
Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version =
2) as appropriate

As far as I can tell, revision 74099
(https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97),
which changes the default serialization format to 3, clashes with
revision 73973 
(https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00),
which checks that serialized R objects are _not_ version 3. It seems
that with the current development version of R, if you `R CMD build`
and then run `R CMD check --as-cran` on the built package, it will
fail.



I think the message basically says:  don't do that.  You should build 
with R-release for now.  You always need to check with R-devel, so life 
is complicated.


If you build with R-devel without forcing the old format, nobody using 
R-release will be able to use your tarball.


Eventually I guess the new format will be accepted by CRAN, but it will 
likely be a while:  nobody expects everyone to instantly upgrade to a 
new R release, let alone to an unreleased development version.


Presumably that particular file (build/vignette.rds) could be 
automatically built in the old format for now, but the new format needs 
testing, so it makes sense to me to leave it as a default, even if it 
makes it more complicated to submit a package to CRAN.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] OpenBLAS in everyday R?

[Juan Telleria]

In order to document the generated Know-How of Optional BLAS Libraries
Implementation and Tests (For example: OpenBLAS), I have created a
Mediawiki based wiki page in which anyone can document and discuss any
issues he/she encounters:

https://kbrproject.miraheze.org/wiki/Main_Page/BLAS

I will myself document all observations and attach the papers that
have been mentioned in R-devel related to such topic.

Hope its useful.

Best,
Juan Telleria

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] OpenBLAS in everyday R?

[Juan Telleria]

> In order to document the generated Know-How of Optional BLAS Libraries
> Implementation and Tests (For example: OpenBLAS), I have created a
> Mediawiki based wiki page in which anyone can document and discuss any
> issues he/she encounters:
>
> https://kbrproject.miraheze.org/wiki/Main_Page/BLAS
>
> I will myself document all observations and attach the papers that
> have been mentioned in R-devel related to such topic.

Will take me some time... Maybe I can finish it at the weekend, That
there is more info that expected.
Juan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] OpenBLAS in everyday R?

[Benjamin Tyner]

Thanks Keith. We checked, and indeed libopenblas is not linked against 
libomp nor libgomp. We suspect this is because we used conda to install 
R and OpenBLAS. So I guess we should be barking up the conda tree instead?


By the way, I also noticed on my home machine (Ubuntu), 
/usr/lib/libopenblas.so.0 is also not linked against those, for what 
that's worth.


Regards,
Ben

On 01/10/2018 12:04 AM, Keith O'Hara wrote:

Check if libopenblas is linked against libomp or libgomp.

I’d be curious to see any errors that arise when an OpenMP version of OpenBLAS 
is linked with R.

Keith



On Jan 9, 2018, at 11:01 PM, Benjamin Tyner  wrote:

I didn't do the compile; is there a way to check whether that was used? If not, 
I'll inquire with our sysadmin and report back.

In any case, my suggestion was motivated by the fact that some parts of R use 
OpenMP while others do not, in the hope that the former could have their 
OpenBLAS omelet without breaking the OpenMP eggs, so to speak.


On 01/09/2018 06:41 PM, Keith O'Hara wrote:

Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ?

Keith


On Jan 9, 2018, at 6:03 PM, Benjamin Tyner  wrote:

Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely 
with multi-threaded OpenMP? (for example, don't race conditions sometimes crop 
up)? If so, it might be nice to have the ability to temporarily disable 
multi-threaded OpenMP (effectively: omp_set_num_threads(1)) for the duration of 
operations using OpenBLAS.

Regards
Ben


Julia using OpenBLAS is *very* reassuring.

I agree that having it included as an options(...) feature should be OK.

On Sun, Dec 17, 2017, 3:22 PM Juan Telleria https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote:


/Julia Programming Language uses also OpenBlas, and it is actively />/maintained with bugs being fixed as I have checked it out: />//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to be included as an options(...) feature (by default />/off, just for safety), over other Blas libraries. />//>/R could not use Intel MKL for legal reasons (I think), because as long />/that R ships with GPL libraries, shipping R by default with Non-GPL is />/illegal. />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" https://stat.ethz.ch/mailman/listinfo/r-devel>> />/escribió: />//>>/On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> It seems like many of the multi-threaded BLASes have some sort of />>/> fundamental problem preventing use in the way Juan suggests: />>/> />>/> - Dirk's vignette states that ATLAS "fixes the number of cores used at />>/> compile-time and cannot vary this setting at run-time", so any />>/> user-friendly 
implementation for R would have to compile ATLAS for 1-16 />>/> threads to allow the user to switch at run-time. This might dramatically />>/> affect install times. />>/> />>/> - MKL seems like it's been outright rejected in the past based on not />>/> being "free-enough". />>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has anyone tried ExBLAS for use with R? />>/> />>/> On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder < />>/> peter.langfelder at gmail.com 
> wrote: />>/> />>/>> I would be very cautious about OpenBLAS in particular... from time to />>/>> time I get complains from users that compiled code calculations in my />>/>> WGCNA package crash or produce wrong answers with large data, and they />>/>> all come from OpenBLAS users. I am yet to reproduce any of their />>/>> crashes when using MKL and ATLAS BLAS implementations. />>/>> />>/>> Just my 2 cents... />>/>> />>/>> Peter 
/>>//>>/I've been building R on Windows 64 bit with OpenBLAS for years and my />>/builds pass check-devel. For a while in the past it failed one check />>/as the tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. I provide descriptions here [1], but I haven't gone so far />>/as to post compiled Rblas.dlls just yet. My personal build sets 4 />>/threads when compiling OpenBLAS itself as I'm currently on a quad-core />>/SandyBridge. In tests I ran a few years ago, both 
single and multi />>/threaded BLAS compile and then can be compiled into R with no issues />>/(on my platforms, at least). Most matrix operations performed better />>/with multi-threaded except for R's eigenvalue decomposition, to the />>/nest of my recollection. />>//>>/Avi />>//>>/[1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ />>//>>/__ />>/R-devel at r-project.org  mailing list 
/>>/https://stat.ethz.ch/mailman/listinfo/r-devel />>//>//

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman