On 14.04.2012 09:01, Tal Galili wrote:
Hello deari Uwe,
What you explain about enableJIT makes sense, except that I would not
expect it to slow down the function in an order of magnitude.
If it was only adding a constant time to the startup time, I would
understand, but I suspect that this is not the case here. For example, see
this code:
enableJIT(0) # making sure that JIT is off
#[1] 3
fo<- function() {for(i in 1:100) {rpart(Kyphosis ~ Age + Number + Start,
data=kyphosis)}}
system.time(fo())
# user system elapsed
# 0.70 0.02 0.78
enableJIT(3)
# [1] 0
system.time(fo())
# user system elapsed
# 10.31 0.00 10.36
If I understand enableJIT, it shoudl compile the functions inside fo and
rpart once (hence the slower startup time), but once that is done, there
should not be an extra overhead. Am I missing something here?
I see, that's indeed suprising. I see Luke as the author of the code is
going to look at it.
In any case, note that rpart is already byte compiled before you start
your evaluations: All base and recommended packages are byte compiled by
default nowadays.
Best,
Uwe
With regards,
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)
----------------------------------------------------------------------------------------------
On Fri, Apr 13, 2012 at 12:47 PM, Uwe Ligges<
lig...@statistik.tu-dortmund.de> wrote:
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/<http://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<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<https://stat.ethz.ch/mailman/listinfo/r-help>
PLEASE do read the posting guide http://www.R-project.org/**
posting-guide.html<http://www.R-project.org/posting-guide.html>
and provide commented, minimal, self-contained, reproducible code.
[[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.
______________________________________________
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.
