R help - Apr 2012 - 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 <- function() {rpart(Kyphosis ~ Age + Number + Start, data=kyphosis)}
system.time(fo())
#   user  system elapsed
#      0       0       0   # this can also be 0.01 sometimes.

enableJIT(2)  # also happens for enableJIT(3)
system.time(fo())
#   user  system elapsed
#   0.12    0.00    0.12


Which brings me to my *questions*:
1) Is this a bug or a feature?
2) If this is a feature, what is causing it? (or put another way, can one
predict ahead of time the implications of using enableJIT(2) or
enableJIT(3) on his code?)


*Links*:
A post I recently wrote about my exploration of JIT -
www.r-statistics.com/2012/04/speed-up-your-r-code-using-a-just-in-time-jit-compiler/
The question asked on SO regarding the limitations of JIT:
http://stackoverflow.com/questions/10106736/possible-shortcomings-for-using-jit-with-r

Thanks,
Tal



----------------Contact
Details:-------------------------------------------------------
Contact me: Tal.Galili@gmail.com |  972-52-7275845
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
----------------------------------------------------------------------------------------------

	[[alternative HTML version deleted]]

On 12.04.2012 23:15, Tal Galili wrote:
> 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 ~ Age + Number + Start, data=kyphosis)}
> system.time(fo())
> #   user  system elapsed
> #      0       0       0   # this can also be 0.01 sometimes.
>
> enableJIT(2)  # also happens for enableJIT(3)
> system.time(fo())
> #   user  system elapsed
> #   0.12    0.00    0.12
>
Because the overhead for JIT is considerable for this example and the 
time critical parts of rpart are written in compiled code already.

JIT compilers are good for inefficiently written R code such as loops 
that could be avoided by vectorized operations. JIT cannot optimize 
runtime for code already written in C (or written in excellent R code).

Uwe Ligges





>
> Which brings me to my *questions*:
> 1) Is this a bug or a feature?
> 2) If this is a feature, what is causing it? (or put another way, can one
> predict ahead of time the implications of using enableJIT(2) or
> enableJIT(3) on his code?)
>
>
> *Links*:
> A post I recently wrote about my exploration of JIT -
>
www.r-statistics.com/2012/04/speed-up-your-r-code-using-a-just-in-time-jit-compiler/
> The question asked on SO regarding the limitations of JIT:
>
http://stackoverflow.com/questions/10106736/possible-shortcomings-for-using-jit-with-r
>
> Thanks,
> Tal
>
>
>
> ----------------Contact
> Details:-------------------------------------------------------
> Contact me: Tal.Galili at gmail.com |  972-52-7275845
> Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
> www.r-statistics.com (English)
>
----------------------------------------------------------------------------------------------
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

The level 2 is a heuristic meant to help with certain kinds of
programming idioms. It isn't always going to work.  In this case
trace(cmpfun) will show three functions being compiled each time
through. Not sure why -- I'll try to find out and see if it can be
avoided.

luke

On Thu, 12 Apr 2012, Tal Galili wrote:
> 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 ~ Age + Number + Start, data=kyphosis)}
> system.time(fo())
> #   user  system elapsed
> #      0       0       0   # this can also be 0.01 sometimes.
>
> enableJIT(2)  # also happens for enableJIT(3)
> system.time(fo())
> #   user  system elapsed
> #   0.12    0.00    0.12
>
>
> Which brings me to my *questions*:
> 1) Is this a bug or a feature?
> 2) If this is a feature, what is causing it? (or put another way, can one
> predict ahead of time the implications of using enableJIT(2) or
> enableJIT(3) on his code?)
>
>
> *Links*:
> A post I recently wrote about my exploration of JIT -
>
www.r-statistics.com/2012/04/speed-up-your-r-code-using-a-just-in-time-jit-compiler/
> The question asked on SO regarding the limitations of JIT:
>
http://stackoverflow.com/questions/10106736/possible-shortcomings-for-using-jit-with-r
>
> Thanks,
> Tal
>
>
>
> ----------------Contact
> Details:-------------------------------------------------------
> Contact me: Tal.Galili at gmail.com |  972-52-7275845
> Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
> www.r-statistics.com (English)
>
----------------------------------------------------------------------------------------------
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu