Displaying 20 results from an estimated 7000 matches similar to: "enableJIT(3) with Primitives"
2012 Mar 21
2
enableJIT() prohibits usual R debugging
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:
2012 Apr 12
2
enableJIT(2) causes major slow-up in rpart
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
2017 Jun 12
2
Possible with enableJIT function
In this email to the R-help list: https://stat.ethz.ch/pipermail/r-help/2017-June/447474.html
and in this question on Stackoverflow: https://stackoverflow.com/questions/44486643/nleqslv-memory-use-in-r
Andrew Leach has raised a question about the memory usage of my package nleqslv.
In a model with a loop within a function he has experienced continuously increasing memory usage
by package nleqslv
2017 Aug 24
2
loop compilation problem
Hi!
We?ve seen a problem with the compiler in specific cases of matrix updates:
> { m <- matrix(1:4, 2) ; z <- 0; for(i in 1) { m[z <- z + 1,z <- z + 1] <- 99; } ; m }
[,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]
2017 Apr 26
4
byte-compiler bug
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 }
foo(c(a=FALSE))
# [1] FALSE # OK
foo(c(a=TRUE))
# [1] TRUE # OK
foo(c(a=FALSE))
# a # ????
# FALSE
The 3rd call returned a result that it different from the 1st
call!
After
2016 Nov 11
2
Frames in compiled functions
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
##
2012 Mar 21
1
enableJIT() and internal R completions (was: [ESS-bugs] ess-mode 12.03; ess hangs emacs)
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 for 'bw.ucv'
2018 Apr 29
2
Result of 'seq' doesn't use compact internal representation
> .Internal(inspect(1:10))
@300e4e8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact)
> .Internal(inspect(seq(1,10)))
@3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,...
> system.time(1:1e7)
user system elapsed
0 0 0
> system.time(seq(1,1e7))
user system elapsed
0.05 0.00 0.04
It seems that result of function 'seq' doesn't use compact
2020 May 24
1
Surpising behavior when using an active binding as loop index in R 4.0.0
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
2018 Apr 29
1
Result of 'seq' doesn't use compact internal representation
Thanks -- I'll commit a fix after some testing.
Best,
luke
On 04/29/2018 06:22 AM, Duncan Murdoch wrote:
> On 28/04/2018 11:11 PM, Suharto Anggono Suharto Anggono via R-devel wrote:
>>> .Internal(inspect(1:10))
>> @300e4e8 13 INTSXP g0c0 [NAM(3)]? 1 : 10 (compact)
>>> .Internal(inspect(seq(1,10)))
>> @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,...
2017 Oct 27
1
Slow down using the compiler
Dear All,
In R 3.4.2 (Linux), the compiler seems to have regressed:
$ R --vanilla
g = function() {
N = 1e7; ans = numeric(N)
system.time({for (j in 1:N) ans[j] = 1})
}
g()
# user system elapsed
# 4.272 0.000 4.272
g1 = compiler::cmpfun(g)
g1()
# user system elapsed
# 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
2015 Aug 12
1
enableJIT in Rprofile leads to 'not a proper evaluation environment' on startup
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:
2015 Jan 22
5
:: and ::: as .Primitives?
Hi all,
When S4 methods are defined on base function (say, "match"), the
function becomes a method with the body "base::match(x,y)". A call to
such a function often spends more time doing "::" than in the function
itself. I always assumed that "::" was a very low-level thing, but it
turns out to be a plain old function defined in base/R/namespace.R.
What
2015 Jan 22
1
:: and ::: as .Primitives?
On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote:
> I'm not convinced that how to make :: faster is the right question. If
> you are finding foo::bar being called often enough to matter to your
> overall performance then to me the question is: why are you calling
> foo::bar more than once? Making :: a bit faster by making it a
> primitive will remove
2015 Jan 22
5
:: and ::: as .Primitives?
On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote:
>
> For default methods there ought to be a way to create those so the
> default method is computed at creation or load time and stored in an
> environment.
We had considered that, but we thought the definition of the function
would be easier to interpret if it explicitly specified the namespace,
instead of
2012 Oct 07
2
malloc error in tab-completion: OS X
I've just built R-devel (r60889) from source on my Mac OS X 10.6.8
using gcc from Xcode and gfortran from Simon. I didn't use all the
recommended configuration flags only
./configure && make
Still, I seem to pass "make check" and
"make test-Segfault" in the tests directory with no problem, but the
following leads
to a persistent error + instant abort.
1)
2013 Jan 09
2
Bug in list subset assignment due to NAMED optimization
In R version 2.15.2 (2012-10-26) i386-apple-darwin9.8.0/i386 (32-bit) I get
the following:
> a <- list(1)
> (a[[1]] <- a)
[[1]]
[[1]][[1]]
[1] 1
but
> a <- list(1)
> b <- a
> (a[[1]] <- a)
[[1]]
[1] 1
And similarly:
> a <- list(x=1)
> (a$x <- a)
$x
$x$x
[1] 1
but
> a <- list(x=1)
> b <- a
> (a$x <- a)
$x
[1] 1
In both cases the
2019 Mar 31
3
stopifnot
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
2015 Jan 23
1
:: and ::: as .Primitives?
Hi,
On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote:
> On Thu, 22 Jan 2015, Michael Lawrence wrote:
>
>> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote:
>>>
>>> For default methods there ought to be a way to create those so the
>>> default method is computed at creation or load time and stored in an
>>>
2017 Jun 13
0
Possible with enableJIT function
Thanks. This should be resolved in R-devel(r72788) and R-patched
(r72789)
Best,
luke
On Mon, 12 Jun 2017, Berend Hasselman wrote:
>
>
> In this email to the R-help list: https://stat.ethz.ch/pipermail/r-help/2017-June/447474.html
> and in this question on Stackoverflow: https://stackoverflow.com/questions/44486643/nleqslv-memory-use-in-r
>
> Andrew Leach has raised a question