4 ms·

I think you could get a lot by chopping out R's non-standard evaluation. It's described pretty well here: http://adv-r.had.co.nz/Computing-on-the-language.html

I think you could get a lot by chopping out R's non-standard evaluation. It's described pretty well here: http://adv-r.had.co.nz/Computing-on-the-language.html http://adv-r.had.co.nz/Computing-on-the-language.html Functions in R are not referentially transparent, so replacing an argument with its value is not necessarily the same. That is a clear restriction on optimizations. If you would want to choose a restricted subset of R to speedup, then this would be a good candidate to cut out since the standard place to compile is at the function level (Numba, Cython, and Julia all do it at functions).

claytonjy 8y ago
I'm not sure this is right; the NSE stuff tends to be at the shell, the user-facing API. The workhorse functions generally are referentially transparent, and writing pure functions is both natural and recommended in R. The slow parts are deeper than the NSE, so removing NSE wouldn't open up much room to optimize. I suspect pass-by-value is a much bigger barrier to speed in R than non-standard evaluation.
- ChrisRackauckas 8y ago
  Oh yes, I forgot about its pass-by-value. Removing pass-by-value is a double edged sword though. I generally dislike it, but you have to admit that having everything pass-by-value is much simpler to a non-programmer. If you chop that out then the "fast R subset" suddenly can act very differently. In order to really write efficient code you'd want to start making use of mutation on this fast part. This means throwing a macro on some array-based R code won't really be automatic: it would need a bit of a re-write for full speed but the re-written version would be incompatible with pass-by-value semantics. This is quite an interesting and tough problem to solve. I think it might be better to keep things pass-by-value and try to optimize pure functions.
- nerdponx 8y ago
  What about copy-on-write semantics? Or is that not a big deal (since you can just "not do it").

claytonjy 8y ago

I'm not sure this is right; the NSE stuff tends to be at the shell, the user-facing API. The workhorse functions generally are referentially transparent, and writing pure functions is both natural and recommended in R. The slow parts are deeper than the NSE, so removing NSE wouldn't open up much room to optimize. I suspect pass-by-value is a much bigger barrier to speed in R than non-standard evaluation.

ChrisRackauckas 8y ago
Oh yes, I forgot about its pass-by-value. Removing pass-by-value is a double edged sword though. I generally dislike it, but you have to admit that having everything pass-by-value is much simpler to a non-programmer. If you chop that out then the "fast R subset" suddenly can act very differently. In order to really write efficient code you'd want to start making use of mutation on this fast part. This means throwing a macro on some array-based R code won't really be automatic: it would need a bit of a re-write for full speed but the re-written version would be incompatible with pass-by-value semantics. This is quite an interesting and tough problem to solve. I think it might be better to keep things pass-by-value and try to optimize pure functions.
nerdponx 8y ago
What about copy-on-write semantics? Or is that not a big deal (since you can just "not do it").