search for: enablejit

Hello, Due to exploration of the JIT capabilities offered through the {compiler} package, I came by the fact that using enableJIT(2) can *slow* the rpart function (from the {rpart} package) by a magnitude of about 10 times. Here is an example code to run: library(rpart) require(compiler) enableJIT(0) # just making sure that JIT is off # We could also use enableJIT(1) and it would be fine fo <- function() {rpart(Kyphosis...

A commenter on SO suggested that I copy my question to R-devel http://stackoverflow.com/q/31972325/850781 I have had --8<---------------cut here---------------start------------->8--- library(compiler) compiler::enableJIT(3) --8<---------------cut here---------------end--------------->8--- in ~/.Rprofile for years; now that I upgraded to 3.2.1 I get this on startup: --8<---------------cut here---------------start------------->8--- Error in frameTypes(env) : not a proper evaluation environment Calls: &l...

Hi, Browser doesn't work properly with the compiler enabled. It might be intended behavior, but it's not documented. compiler::enableJIT(1) foo <- function(){ browser() cat("here\n") } Browser doesn't stop, and I am getting: > foo() Called from: foo() Browse[1]> here > Thanks, Vitalie. > sessionInfo() R version 2.14.2 (2012-02-29) Platform: i686-pc-linux-gnu (32-bit) locale: [1] LC_CTYP...

I'm not sure if this is a bug or expected behavior, but I don't see anything in the documentation that explains it, so I thought I'd mention it: ~ michaelweylandt$ R -q --vanilla library(compiler) enableJIT(3) `+` # Throws an error `+` # Throws a warning `+` # Prints the primitive as expected sessionInfo() R version 2.14.1 (2011-12-22) Platform: i386-apple-darwin9.8.0/i386 (32-bit) 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] compiler stat...

...he function is not byte-compiled so is behaving as expected. 2) However after the 2nd call, the function gets automatically compiled. This seems to be a new feature in R 3.4.0 but you'll have to grep the NEWS file to find out (search for JIT). The man page for cmpfun/enableJIT nicely explains the JIT levels but I couldn't find anywhere that the level is set to 3 by default. I don't even know how one is supposed to get the current level. Calling enableJIT() to change the level returns a value, and this value might look like the previo...

...mem_used())) > [1] "At end memory used is 29126472" > </output> > > Indeed memory used increases in each pass of the for loop. > > I have added these two lines at the top of the code after the library(pryr) invocation. > > library(compiler) > oldJIT <- enableJIT(0) > > This resolves the issue in the sense that memory used remains constant after the first iteration. > Output in the for loop is now: > <output> > [1] "nleqslv iteration 1 and memory used is 24487784" > [1] "nleqslv iteration 2 and memory used is 24495816&...

I noticed some problems that cropped in the latest versions of R-devel (2016-11-08 r71639 in my case) for one of my packages. I _think_ I have narrowed it down to the changes to what gets byte-compiled by default. The following example run illustrates the problem I'm having: compiler::enableJIT(0) fun <- function(x) local(as.list(parent.frame(2))) fun(1) ## $x ## [1] 1 ## compiler::cmpfun(fun)(1) ## <contents of .GlobalEnv> Is this considered problematic at all? If so, might it make sense to broaden the list of functions that disable JIT compilation beyond...

Thanks for the report. Fixed in R_devel with r72631; I'll port to R-patched later today or tomorrow. The default setting and how to get the current settings are documented in the Details section of the enableJIT help page at the end of the paragraph for enableJIT. Best, luke On Wed, 26 Apr 2017, Herv? Pag?s wrote: > Hi, > > I'm running into a case where byte-compilation changes > the semantic of a function. This is with R 3.4.0: > > foo <- function(x) { TRUE && x } &g...

...(paste("At end memory used is", mem_used())) [1] "At end memory used is 29126472" </output> Indeed memory used increases in each pass of the for loop. I have added these two lines at the top of the code after the library(pryr) invocation. library(compiler) oldJIT <- enableJIT(0) This resolves the issue in the sense that memory used remains constant after the first iteration. Output in the for loop is now: <output> [1] "nleqslv iteration 1 and memory used is 24487784" [1] "nleqslv iteration 2 and memory used is 24495816" [1] "nleqslv itera...

...[,1] [,2] [1,] 1 3 [2,] 2 99 Here, it modifies element [2,2], which is unexpected. It behaves correct without the loop: > { m <- matrix(1:4, 2) ; z <- 0; m[z <- z + 1,z <- z + 1] <- 99 ; m } [,1] [,2] [1,] 1 99 [2,] 2 4 ? and without the jit: > enableJIT(0) [1] 3 > { m <- matrix(1:4, 2) ; z <- 0; for(i in 1) { m[z <- z + 1,z <- z + 1] <- 99; } ; m } [,1] [,2] [1,] 1 99 [2,] 2 4 I checked with "R Under development (unstable) (2017-08-23 r73116)?, and the problem is still there. - Lukas

Hello, JIT compiler interferes with internal R completions: compiler::enableJIT(2) utils:::functionArgs("density", '') gives: utils:::functionArgs("density", '') Note: no visible global function definition for 'bw.nrd0' Note: no visible global function definition for 'bw.nrd' Note: no visible global function definition fo...

...0.04 It seems that result of function 'seq' doesn't use compact internal representation. However, looking at the code of function 'seq.default', seq(1,n) produces 1:n. What is going on? > h <- seq.default > environment(h) <- .GlobalEnv > library(compiler) > enableJIT(0) [1] 3 > .Internal(inspect(h(1,10))) @375ade8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) A non-byte-compiled version of function 'seq.default' can produce object that uses compact internal representation. > sessionInfo() R version 3.5.0 (2018-04-23) Platform: i386-w64-mingw32/i386...

It looks like the byte compiler is optimizing local() to an immediately-invoked function, instead of using eval() and substitute(). I don't know if that's exactly how it's implemented internally, but that's what it looks like here: compiler::enableJIT(0) fun <- function(x) { local(sys.calls()) } fun(1) ## [[1]] ## fun(1) ## ## [[2]] ## local(sys.calls()) ## ## [[3]] ## eval.parent(substitute(eval(quote(expr), envir))) ## ## [[4]] ## eval(expr, p) ## ## [[5]] ## eval(expr, envir, enclos) ## call ## [[6]] ## eval(quote(sys.calls()), new.env...

...ficant performance drops (here, computation time increasing from 0.01s to 0.31s ...) ================================= library(Matrix) someMatrix <- new("dtCMatrix", i= c(1L, 0:3), p=c(0L,0L,0:2, 5L), Dim = c(5L, 5L), x = rep(1, 5), diag = "U") compiler::enableJIT(3) ## R-devel default system.time(replicate(100,Matrix::crossprod(someMatrix))) ## slow ! compiler::enableJIT(0) system.time(replicate(100,Matrix::crossprod(someMatrix))) ## fast ================================== By tracing compiler::cmpfun, I found that the reason may be that invoking Matrix::cr...

...t (search for > JIT). The NEWS file is where we usually report news, so this isn't really that much of a surprise. If you don't want to read it all at once, you can see it as it changes on the RSS feed at http://developer.r-project.org/RSSfeeds.html The man page for cmpfun/enableJIT nicely explains > the JIT levels but I couldn't find anywhere that the level > is set to 3 by default. I don't even know how one is > supposed to get the current level. Calling enableJIT() to > change the level returns a value, and this value might >...

...but this does not for (i in 1) { window(z, start = c(1955, 1), end = c(1955, 1)) <- NA } # Error in stats::window(x = `*tmp*`, start = c(1955, 1), end = c(1955, : # object '*tmp*' not found # turning off the byte compiler makes it working again (as in older R versions) compiler::enableJIT(0) for (i in 1) { window(z, start = c(1955, 1), end = c(1955, 1)) <- NA } Any help is very much appreciated. Thanks, Christoph

A shorter reproducible example: example(makeActiveBinding) for (fred in 1:3) { 0 } ls() Both problems go away if you first do compiler::enableJIT(2) So looks like a bug in compiling the for loop. -Deepayan On Sat, May 23, 2020 at 5:45 PM Thomas Friedrichsmeier via R-devel <r-devel at r-project.org> wrote: > > Possibly just a symptom of the earlier behavior, but I'll amend my > example, below, with an even more disturbin...

...lapsed # 4.232 0.004 4.235 Running the above code in Windows 3.3.1, g() takes the same time, but g1() takes around 0.5 seconds. Removing the function wrapper we have N = 1e7; ans = numeric(N) system.time({for (j in 1:N) ans[j] = 1}) # user system elapsed # 0.304 0.000 0.304 compiler::enableJIT(0) #[1] 3 N = 1e7; ans = numeric(N) system.time({for (j in 1:N) ans[j] = 1}) # user system elapsed # 5.448 0.000 5.446 Best wishes Colin ------------------ > sessionInfo() R version 3.4.2 (2017-09-28) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.3 LTS Matrix pr...

...4 [] (len=10, tl=0) 1,2,3,4,5,... > > .Internal(inspect(seq2(1,10))) > @7fa537fa0bf0 13 INTSXP g0c0 [NAM(3)]? 1 : 10 (compact) > > Duncan Murdoch > >> >>> h <- seq.default >>> environment(h) <- .GlobalEnv >>> library(compiler) >>> enableJIT(0) >> [1] 3 >>> .Internal(inspect(h(1,10))) >> @375ade8 13 INTSXP g0c0 [NAM(3)]? 1 : 10 (compact) >> >> A non-byte-compiled version of function 'seq.default' can produce >> object that uses compact internal representation. >> >> >>&g...

Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found Is this accidental feature going to be relied upon? "Details" section of 'stopifnot' do...