Re: [R] enableJIT(2) causes major slow-up in rpart
Thank you very much Luke,
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 11:58 PM, luke-tier...@uiowa.edu wrote:
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.120.000.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/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-rhttp://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-helphttps://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.
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
[[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.
Re: [R] enableJIT(2) causes major slow-up in rpart
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.700.020.78
enableJIT(3)
# [1] 0
system.time(fo())
# user system elapsed
# 10.310.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?
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.120.000.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-rhttp://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-helphttps://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.
Re: [R] enableJIT(2) causes major slow-up in rpart
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.700.020.78
enableJIT(3)
# [1] 0
system.time(fo())
# user system elapsed
# 10.310.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.120.000.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-rhttp://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-helphttps://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/**
posting-guide.htmlhttp://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.
Re: [R] enableJIT(2) causes major slow-up in rpart
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.120.000.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.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.
__
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.
Re: [R] enableJIT(2) causes major slow-up in rpart
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.120.000.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.
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
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] 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.120.000.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.
