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.gal...@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@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.
