similar to: Unnecesary code?

Hi, As the subject suggests, I am looking for the most robust way to call an (arbitrary) function from the R API from another but the main POSIX thread in a package's code. I know that, "[c]alling any of the R API from threaded code is ?for experts only? and strongly discouraged. Many functions in the R API modify internal R data structures and might corrupt these data structures if

On Thu, Jan 15, 2015 at 3:55 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > Just wanted to start a discussion on whether R could ship with more > appropriate GC parameters. I've been doing a number of similar measurements, and have come to the same conclusion. R is currently very conservative about memory usage, and this leads to unnecessarily poor performance on

>>>>> Peter Haverty <haverty.peter at gene.com> >>>>> on Mon, 19 Jan 2015 08:50:08 -0800 writes: > Hi All, This is a very important issue. It would be very > sad to leave most users unaware of a free speedup of this > size. These options don't appear in the R --help > output. They really should be added there. Indeed,

Stepan, Andreas gave a lot more thought into what you question in your reply. His question was how you can avoid what you where proposing and have proper threading under safe conditions. Having dealt with this before, I think Andreas' write up is pretty much the most complete analysis I have seen. I'd wait for Luke to chime in as the ultimate authority if he gets to it. The

Just wanted to start a discussion on whether R could ship with more appropriate GC parameters. Right now, loading the recommended package Matrix leads to: > library(Matrix) > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 1076796 57.6 1368491 73.1 1198505 64.1 Vcells 1671329 12.8 2685683 20.5 1932418 14.8 Results may vary, but here R needed 64MB of N cells and 15MB

As I mentioned in my previous message about speeding up evalList, I've been looking at ways to speed up the R interpreter. One sees in the code many, many calls of PROTECT, UNPROTECT, and related functions, so that seems like an obvious target for optimization. Indeed, I've found that one can speed up the interpreter by about 10% by just changing these. The functions are actually macros

--- src/libFLAC/bitwriter.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/src/libFLAC/bitwriter.c b/src/libFLAC/bitwriter.c index 651440d..7da4b15 100644 --- a/src/libFLAC/bitwriter.c +++ b/src/libFLAC/bitwriter.c @@ -43,12 +43,11 @@ /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this

Full_Name: John Brzustowski Version: R-devel trunk and R-2.4.0 OS: linux Submission from: (NULL) (76.10.152.79) Here are two minor potential issues in pointer protection stack (PPS) code which could arise in debugging R with valgrind. Only the second could possibly cause a problem in normal use of R, and only under laughably implausible circumstances. (1) valgrind is given a wrong address when

Dear All, I'm linking R from another application and embedding it as described in the R-exts manual, i.e. with initialization done via Rf_initEmbeddedR. While everything works the same as in standalone R for Linux, under Windows I found a difference in the default memory.limit, which is fixed to 2GB (both win32 and win64) - compared to a limit in standalone R of 3.5GB for win32 and 16GB on

Dear R developers, The slow performance of serializing to a raw vector on Windows is an issue that has appeared in this list before. It appears to be due to the frequent use of realloc from the resize_buffer method in serialize.c. I suggest a more granular, but still incremental, re-allocation of memory. For example change near the top of resize_buffer to: R_size_t newsize = needed + 65536 -

Hello! I'm getting SING errors from the log() function. Here is the code inside the vbr_analysis() function. if (ener<60000) { if (vbr->consec_noise>2) qual-=0.5*(log(3.0 + vbr->consec_noise)-log(3)); if (ener<10000&&vbr->consec_noise>2) qual-=0.5*(log(3.0 + vbr->consec_noise)-log(3)); if (qual<0) qual=0;

I am using the Deepayan's Sweave trick to set graphics parameters for all graphs: ltheme = canonical.theme(color=TRUE) sup = trellis.par.get("superpose.line") ltheme$superpose.line$col = c('black',"red","blue","#e31111","green", "gray") .... Works perfectly, there is only a minor nuissance that trellis.par.get opens a device

Your analysis looks pretty complete to me and your solutions seems plausible. That said, I don't know that I would have the level of confidence yet that we haven't missed an important point that I would want before going down this route. Losing stack checking is risky; it might be eventually possible to provide some support for this to be handled via a thread-local variable. Ensuring

Hi Andreas, note that with the introduction of ALTREP, as far as I understand, calls as "simple" as DATAPTR can execute arbitrary code (R or native). Even without ALTREP, if you execute user-provided R code via Rf_eval and such on some custom thread, you may end up executing native code of some package, which may assume it is executed only from the R main thread. Could you (1)

Dear R-ers, I don't understand the following, maybe someone will help me explain: > setClasss('A') [1] "A" > new('a') Error in new("a") : trying to generate an object from a virtual class ("a") > setClass('b', contains='a') [1] "b" > new('b') An object of class ?b? <S4 Type Object> In what

When large calls cause errors R may stall for extended periods.? This is particularly likely to happen with `do.call`, as in this example with a 24 second stall: ??? x <- runif(1e7) ??? system.time(do.call(paste0, list(abs, x)))? # intentional error ??? ## Error in (function (..., collapse = NULL)? : ??? ##?? cannot coerce type 'builtin' to vector of type 'character' ??? ##

please keep the list cc'ed when replying me. ---------- Forwarded message ---------- From: Andreas Thienemann <andreas@bawue.net> Date: 15 nov. 2005 15:36 Subject: Re: RE New xanto driver for NUT To: Arnaud Quette <aquette.dev@gmail.com> Hello Arnaud, On Tue, 15 Nov 2005, Arnaud Quette wrote: > is there really a need to separate it from the megatec. > we're currently

please keep the list cc'ed when replying me. ---------- Forwarded message ---------- From: Andreas Thienemann <andreas@bawue.net> Date: 15 nov. 2005 15:36 Subject: Re: RE New xanto driver for NUT To: Arnaud Quette <aquette.dev@gmail.com> Hello Arnaud, On Tue, 15 Nov 2005, Arnaud Quette wrote: > is there really a need to separate it from the megatec. > we're currently

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a