[Rd] Nice names in deparse
Tags (argument names) in call to 'list' becomes names of the result. It is not
necessarily so with call to 'c'. The default method of 'c' has 'recursive' and
'use.names' arguments.
In R devel r73778, with
x <- 0; names(x) <- "recursive" ,
dput(x)
or even
dput(x, control = "all")
gives
c(recursive = 0)
However, actual result of c(recursive = 0) is NULL.
Also with
x <- 0; names(x) <- "recursive" ,
dput(x, control = c("keepNA", "keepInteger", "showAttributes"))
in R devel r73778
gives
structure(c(0), .Names = "recursive")
The 'control' is suggested by an example for output as in R < 3.5.0. However,
the output is slightly different from
dput(x)
in R 3.3.2:
structure(0, .Names = "recursive")
Part of NEWS item related with "niceNames" control option:
as.character(list( c (one = 1))) now includes the name, as
as.character(list(list(one = 1))) has always done.
Please reconsider.
As
as.numeric(list(c(one = 1)))
gives
1 ,
I expect that
as.character(list(c(one = "1")))
gives
"1" .
It does in R devel r73778.
Why does
as.character(list(c(one = 1)))
give
"c(one = 1)" ?
as.numeric(list(c(one = "1")))
gives
1 .
list(list(one = 1))
is not quite the same.
as.numeric(list(list(one = 1)))
gives
NA .
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot destroy connection (?) created by readLines in a tryCatch
On Fri, 15 Dec 2017, Gábor Csárdi wrote:
Thanks for tracking this down. Yeah, I should use suppressWarnings(),
you are right.
Although, readLines() might throw another warning, e.g. for incomplete
last lines,
Do whatever makes sense for your context.
My main point is: if you want your computation to be able to handle a
warning and possibly continue after that then you need to use a
calling handler, not an exiting one.
Best,
luke
and you don't necessarily want to suppress that.
TBH I am not sure why that warning is given:
❯ con <- file(tempfile())
❯ open(con)
Error in open.connection(con) : cannot open the connection
In addition: Warning message:
In open.connection(con) :
cannot open file
'/var/folders/59/0gkmw1yj2w7bf2dfc3jznv5wgn/T//RtmpilJLXL/filed0ab5adb9a18':
No such file or directory
It seems that open() also throws an error, so why give the warning?
Because it is more specific?
Would it make sense to turn that warning into an error?
Gabor
On Thu, Dec 14, 2017 at 11:46 PM, wrote:
This has nothing to do with on.exit. It is an iteraction between where
the warning is signaled in 'file' and your _exiting_ warning handler.
This combination has the same issue,
tryCatch(file(tempfile(), "r"), warning = identity)
showConnections(all = TRUE)
as does
options(warn=2)
file(tempfile(), "r")
showConnections(all = TRUE)
I haven't looked at the internals of 'file' but it looks like
what it does is
add an entry to connections table
warn about non-existent file
realize it has to fail
remove the connections table entry
signal an error
This misses the possibility that the warning can result in a jump
if it is turned into a error or handled by an exiting handler.
It's worth filing a bug report on 'file'.
It's not clear what you are really trying to do, but establishing
an _exiting_ handler for warnings is usually not what you
want. If you are trying to suppress warnings you need to use a
calling handler, e.g. via suppressWarnings. If you want to do
something more sophisticated that does not terminate the
computation on a warniing you can build on what suppressWarnigns
does.
Best,
luke
On Thu, 14 Dec 2017, Gábor Csárdi wrote:
On Thu, Dec 14, 2017 at 7:56 PM, Gabriel Becker
wrote:
Gabor,
You can grab the connection and destroy it via getConnection and then a
standard close call.
Yeah, that's often a possible workaround, but since this connection
was opened by
readLines() internally, I don't necessarily know which one it is. E.g.
I might open multiple
connections to the same file, so I can't choose based on the file name.
Btw. this workaround seems to work for me:
read_lines <- function(con, ...) {
if (is.character(con)) {
con <- file(con)
on.exit(close(con))
}
readLines(con, ...)
}
This is basically the same as readLines(), but on.exit() does its job
here.
That's another clue that it might be an on.exit() issue. Wild guess:
on.exit() does not run if an internal function errors.
(it actually lists that it is "closed" already, but
still in the set of existing connections. I can't speak to that
difference).
It is closed but not destroyed.
G.
tryCatch(
+ readLines(tempfile(), warn = FALSE)[1],
+ error = function(e) NA,
+ warning = function(w) NA
+ )
[1] NA
rm(list=ls(all.names = TRUE))
gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 257895 13.8 592000 31.7 416371 22.3
Vcells 536411 4.18388608 64.0 1795667 13.7
showConnections(all = TRUE)
description
0 "stdin"
1 "stdout"
2 "stderr"
3
"/var/folders/79/l_n_5qr152d2d9d9xs0591lhgn/T//RtmpZRcxmh/file128a13bffc77"
class mode text isopen can read can write
0 "terminal" "r" "text" "opened" "yes""no"
1 "terminal" "w" "text" "opened" "no" "yes"
2 "terminal" "w" "text" "opened" "no" "yes"
3 "file" "r" "text" "closed" "yes""yes"
con = getConnection(3)
con
A connection with
description
"/var/folders/79/l_n_5qr152d2d9d9xs0591lhgn/T//RtmpZRcxmh/file128a13bffc77"
class "file"
mode"r"
text"text"
opened "closed"
can read"yes"
can write "yes"
close(con)
showConnections(all=TRUE)
description class mode text isopen can read can write
0 "stdin" "terminal" "r" "text" "opened" "yes""no"
1 "stdout""terminal" "w" "text" "opened" "no" "yes"
2 "stderr""terminal" "w" "text" "opened" "no" "yes"
HTH,
~G
On Thu, Dec 14, 2017 at 10:02 AM, Gábor Csárdi
wrote:
Consider this code. This is R 3.4.2, but based on a quick look at the
NEWS, this has not been fixed.
tryCatch(
readLines(tempfile(), warn = FALSE)[1],
error = function(e) NA,
warning = function(w) NA
)
rm(list=ls(all.names = TRUE))
gc()
showConnections(all = TRUE)
If you run it, you'll get a connection you cannot close(), i.e. the
last showConnections() call prints:
❯ showConnections(all = TRUE)
description
0 "stdin"
1 "stdout"
2 "stderr"
3
"/va
[Rd] OpenBLAS in everyday R?
Hi R-devel list, OpenBLAS is readily available for unix-likes: https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf However, my questions are: 1) Would R-devel consider using OpenBLAS for the main distribution of R for all platforms including Windows? 2) If so, would R-devel set the default multi-thread level to the number of (real) cores on a machine? My sense is there're a lot of wasted resources on laptops and personal desktops around the world that could be utilised by such a switch. I believe most unix-like users don't know about OpenBLAS and are blissfully ignorant of the available speed gains. It seems to be quite difficult for a typical Windows user to get this done today. Thanks heaps, Kenny [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
Kenny, On 17 December 2017 at 09:28, Kenny Bell wrote: | Hi R-devel list, | | OpenBLAS is readily available for unix-likes: | | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf Please consider re-reading this vignette of mine. BLAS is an interface, OpenBLAS is but one implementation. R has allowed you to switch between different implementations for a long time (if you used a shared library build), and illustrating / measuring the possible performance differences is the whole point of the gcbd benchmarking package. | However, my questions are: | | 1) Would R-devel consider using OpenBLAS for the main distribution of R for | all platforms including Windows? | 2) If so, would R-devel set the default multi-thread level to the number of | (real) cores on a machine? It's complicated. If you fork at the process-level (with package parallel or one of the many other mechansim) and then also used multi-threaded BLAS you can starve yourself for resources quickly. | My sense is there're a lot of wasted resources on laptops and personal | desktops around the world that could be utilised by such a switch. I | believe most unix-like users don't know about OpenBLAS and are blissfully | ignorant of the available speed gains. It seems to be quite difficult for a | typical Windows user to get this done today. Many things a developer / power-user would do are very difficult on Windows. It is one of the charms of the platform. On the other hand you do get a few solitaire games so I guess everybody is happy. Dirk | Thanks heaps, | Kenny | | [[alternative HTML version deleted]] | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
On point 1): The standard approach seems to favor the reference BLAS for reasons other than speed. For example, vecLib, Apple's multi-threaded BLAS library, is not the default choice for macOS binaries due to concerns about 'precision'. See: https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic h-BLAS-is-used-and-how-can-it-be-changed_003f This doesn't appear to be Mac- or vecLib-specifc. R-Core seem wary of non-reference BLAS implementations for several reasons: 'External BLAS implementations often make less use of extended-precision floating-point registers and will almost certainly re-order computations. This can result in less accuracy than using the internal BLAS, and may result in different solutions, e.g. different signs in SVD and eigendecompositions.' https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#BLAS I'm not sure how pervasive a problem this is, though. Keith On Sat, Dec 16, 2017 at 4:01 PM, Dirk Eddelbuettel wrote: > > Kenny, > > On 17 December 2017 at 09:28, Kenny Bell wrote: > | Hi R-devel list, > | > | OpenBLAS is readily available for unix-likes: > | > | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > Please consider re-reading this vignette of mine. BLAS is an interface, > OpenBLAS is but one implementation. R has allowed you to switch between > different implementations for a long time (if you used a shared library > build), and illustrating / measuring the possible performance differences > is > the whole point of the gcbd benchmarking package. > > | However, my questions are: > | > | 1) Would R-devel consider using OpenBLAS for the main distribution of R > for > | all platforms including Windows? > | 2) If so, would R-devel set the default multi-thread level to the number > of > | (real) cores on a machine? > > It's complicated. If you fork at the process-level (with package parallel > or > one of the many other mechansim) and then also used multi-threaded BLAS you > can starve yourself for resources quickly. > > | My sense is there're a lot of wasted resources on laptops and personal > | desktops around the world that could be utilised by such a switch. I > | believe most unix-like users don't know about OpenBLAS and are blissfully > | ignorant of the available speed gains. It seems to be quite difficult > for a > | typical Windows user to get this done today. > > Many things a developer / power-user would do are very difficult on > Windows. It is one of the charms of the platform. On the other hand you do > get a few solitaire games so I guess everybody is happy. > > Dirk > > | Thanks heaps, > | Kenny > | > | [[alternative HTML version deleted]] > | > | __ > | R-devel@r-project.org mailing list > | https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-devel@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/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
On Sun, Dec 17, 2017 at 10:01 AM, Dirk Eddelbuettel wrote: > > Kenny, > > On 17 December 2017 at 09:28, Kenny Bell wrote: > | Hi R-devel list, > | > | OpenBLAS is readily available for unix-likes: > | > | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > Please consider re-reading this vignette of mine. BLAS is an interface, > OpenBLAS is but one implementation. R has allowed you to switch between > different implementations for a long time (if you used a shared library > build), and illustrating / measuring the possible performance differences > is > the whole point of the gcbd benchmarking package. > Understood. To be clear, my suggestion is to change the *default* BLAS implementation to multithreaded OpenBLAS. > | However, my questions are: > | > | 1) Would R-devel consider using OpenBLAS for the main distribution of R > for > | all platforms including Windows? > | 2) If so, would R-devel set the default multi-thread level to the number > of > | (real) cores on a machine? > > It's complicated. If you fork at the process-level (with package parallel > or > one of the many other mechansim) and then also used multi-threaded BLAS you > can starve yourself for resources quickly. > > This indeed was my experience if not being careful when using MRO, which also has a multithreaded algebra library as the default. However, the overall speed benefits far outweighed the costs. MRO helped to overcome this problem with an interface to change the number of threads to use. In MRO, it is on the user to switch this before using any explicit parallel functionality. Another question, does using multithreaded OpenBLAS mess with RcppParallel? > | My sense is there're a lot of wasted resources on laptops and personal > | desktops around the world that could be utilised by such a switch. I > | believe most unix-like users don't know about OpenBLAS and are blissfully > | ignorant of the available speed gains. It seems to be quite difficult > for a > | typical Windows user to get this done today. > > Many things a developer / power-user would do are very difficult on > Windows. It is one of the charms of the platform. On the other hand you do > get a few solitaire games so I guess everybody is happy. > > Dirk > > | Thanks heaps, > | Kenny > | > | [[alternative HTML version deleted]] > | > | __ > | R-devel@r-project.org mailing list > | https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
It seems that reproducibility across systems is also an issue with multithreaded BLASes: https://hal.archives-ouvertes.fr/hal-01202396/file/exblas.pdf On Sun, Dec 17, 2017 at 11:50 AM, Keith O'Hara wrote: > On point 1): > > The standard approach seems to favor the reference BLAS for reasons other > than speed. > > For example, vecLib, Apple's multi-threaded BLAS library, is not the > default choice for macOS binaries due to concerns about 'precision'. See: > > https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic > h-BLAS-is-used-and-how-can-it-be-changed_003f > > This doesn't appear to be Mac- or vecLib-specifc. R-Core seem wary of > non-reference BLAS implementations for several reasons: > > 'External BLAS implementations often make less use of extended-precision > floating-point registers and will almost certainly re-order computations. > This can result in less accuracy than using the internal BLAS, and may > result in different solutions, e.g. different signs in SVD and > eigendecompositions.' > > https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#BLAS > > I'm not sure how pervasive a problem this is, though. > > Keith > > > On Sat, Dec 16, 2017 at 4:01 PM, Dirk Eddelbuettel wrote: > >> >> Kenny, >> >> On 17 December 2017 at 09:28, Kenny Bell wrote: >> | Hi R-devel list, >> | >> | OpenBLAS is readily available for unix-likes: >> | >> | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf >> >> Please consider re-reading this vignette of mine. BLAS is an interface, >> OpenBLAS is but one implementation. R has allowed you to switch between >> different implementations for a long time (if you used a shared library >> build), and illustrating / measuring the possible performance differences >> is >> the whole point of the gcbd benchmarking package. >> >> | However, my questions are: >> | >> | 1) Would R-devel consider using OpenBLAS for the main distribution of R >> for >> | all platforms including Windows? >> | 2) If so, would R-devel set the default multi-thread level to the >> number of >> | (real) cores on a machine? >> >> It's complicated. If you fork at the process-level (with package parallel >> or >> one of the many other mechansim) and then also used multi-threaded BLAS >> you >> can starve yourself for resources quickly. >> >> | My sense is there're a lot of wasted resources on laptops and personal >> | desktops around the world that could be utilised by such a switch. I >> | believe most unix-like users don't know about OpenBLAS and are >> blissfully >> | ignorant of the available speed gains. It seems to be quite difficult >> for a >> | typical Windows user to get this done today. >> >> Many things a developer / power-user would do are very difficult on >> Windows. It is one of the charms of the platform. On the other hand you do >> get a few solitaire games so I guess everybody is happy. >> >> Dirk >> >> | Thanks heaps, >> | Kenny >> | >> | [[alternative HTML version deleted]] >> | >> | __ >> | R-devel@r-project.org mailing list >> | https://stat.ethz.ch/mailman/listinfo/r-devel >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> >> __ >> R-devel@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/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
Multi-threaded Math Libraries (Trough OpenBlas), taking into account that today's laptops have a minimum of 2-4 cores, are an important topic, and in my opinion, shall be included in R for the general interest. I think that the way to go would be to create a configuration setting in R's options(OpenBlas= TRUE|FALSE) which enables or disables OpenBlas in an easy way, which by default shall be in FALSE (In order to avoid issues with parallel libraries). The key point would be that each time you open a new R session, a 1 liner informative comment arises that tells you: a) Whether OpenBlas is enabled or disabled. b) And how many cores it uses (Setting also configurable through options(...)) In a shape just as Microsoft R Open does. Kind regards, Juan Telleria [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
Multi-threaded Math Libraries (Trough OpenBlas), taking into account that today's laptops have a minimum of 2-4 cores, are an important topic, and in my opinion, shall be included in R for the general interest. I think that the way to go would be to create a configuration setting in R's options(OpenBlas=TRUE|FALSE) which enables or disables OpenBlas in an easy way, which by default shall be in FALSE (In order to avoid issues with parallel libraries). The key point would be that each time you open a new R session, a 1 liner informative comment arises that tells you: a) Whether OpenBlas is enabled or disabled. b) And how many cores it uses (Setting also configurable through options(...)) In a shape just as Microsoft R Open does. Kind regards, Juan Telleria El 17/12/2017 12:31 a. m., "Juan Telleria" escribió: > Multi-threaded Math Libraries (Trough OpenBlas), taking into account that > today's laptops have a minimum of 2-4 cores, are an important topic, and in > my opinion, shall be included in R for the general interest. > > I think that the way to go would be to create a configuration setting in > R's options(OpenBlas= TRUE|FALSE) which enables or disables OpenBlas in an > easy way, which by default shall be in FALSE (In order to avoid issues with > parallel libraries). > > The key point would be that each time you open a new R session, a 1 liner > informative comment arises that tells you: > a) Whether OpenBlas is enabled or disabled. > b) And how many cores it uses (Setting also configurable through > options(...)) > > In a shape just as Microsoft R Open does. > > Kind regards, > Juan Telleria > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
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 On Sat, Dec 16, 2017 at 12:28 PM, Kenny Bell wrote: > Hi R-devel list, > > OpenBLAS is readily available for unix-likes: > > https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > However, my questions are: > > 1) Would R-devel consider using OpenBLAS for the main distribution of R for > all platforms including Windows? > 2) If so, would R-devel set the default multi-thread level to the number of > (real) cores on a machine? > > My sense is there're a lot of wasted resources on laptops and personal > desktops around the world that could be utilised by such a switch. I > believe most unix-like users don't know about OpenBLAS and are blissfully > ignorant of the available speed gains. It seems to be quite difficult for a > typical Windows user to get this done today. > > Thanks heaps, > Kenny > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
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.langfel...@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 > > On Sat, Dec 16, 2017 at 12:28 PM, Kenny Bell wrote: > > Hi R-devel list, > > > > OpenBLAS is readily available for unix-likes: > > > > https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > > > However, my questions are: > > > > 1) Would R-devel consider using OpenBLAS for the main distribution of R > for > > all platforms including Windows? > > 2) If so, would R-devel set the default multi-thread level to the number > of > > (real) cores on a machine? > > > > My sense is there're a lot of wasted resources on laptops and personal > > desktops around the world that could be utilised by such a switch. I > > believe most unix-like users don't know about OpenBLAS and are blissfully > > ignorant of the available speed gains. It seems to be quite difficult > for a > > typical Windows user to get this done today. > > > > Thanks heaps, > > Kenny > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@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/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell 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.langfel...@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
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" escribió: > On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell 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.langfel...@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@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/listinfo/r-devel
Re: [Rd] OpenBLAS in everyday R?
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 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" > escribió: > >> On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell 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.langfel...@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@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/listinfo/r-devel
