Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Journey from R to Julia

drtomasaragon.github.io

Post reply on HN
Print view View original

41–50 of 120 posts

Re: My Journey from R to Julia

#41

Post by em500 »

pxmpxm wrote: post #31
em500 wrote: post #9

Earlier quoted context omitted.

So Rob Pike’s rule 1 and 2 again: Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. https://users.ece.utexas.edu/~adnan/pike.htm…

That's some pretty generic premature optimization cargo culting. If you have a huge data set and some understanding what you're doing, the bottlebecks will be pretty obvious.

Apparently not obvious enough for people to estimate in advance if they should avoid looping.

Pike point is not just to avoid premature optimization. It’s to measure bottlenecks. Because due to changing language and hardware developments, what you think you knew to be true might become outdated.

Re: My Journey from R to Julia

#42

Post by kruxigt »

sfpotter wrote: post #37
borodi wrote: post #22

Earlier quoted context omitted.

One interesting thing is that if julia can prove what types a function will be called with at compile time, it doesn't have to do dynamic dispatch, so it has no overhead. It's what the julia folks call type-stable code

If ifs and buts were candy and nuts...

[dead]

Re: My Journey from R to Julia

#43

Post by ChrisRackauckas »

BrandonS113 wrote: post #33
ChrisRackauckas wrote: post #30

Earlier quoted context omitted.

Did you use JuMP? It would be interesting to see the JuMP code.

No, nlopt. Why we could easy port from R to Julia as nlopt exists for both (its c)

Ahh then it's all based on the speed of the objective function and the gradient calculation code. Do you have an example to look at for that? Or did you try modelingtoolkitizing and running an auto-simplified form?

Re: My Journey from R to Julia

#44

Post by harshreality »

BrandonS113 wrote: post #33
ChrisRackauckas wrote: post #30

Earlier quoted context omitted.

Did you use JuMP? It would be interesting to see the JuMP code.

No, nlopt. Why we could easy port from R to Julia as nlopt exists for both (its c)

If you use the same native C library from both Julia and some other language, and (presumably) that library is where the algorithm spends the vast majority of its time, why would you expect Julia to be faster?

Re: My Journey from R to Julia

#45

Post by getoffmycase »

vitorsr wrote: post #14

This has been said before multiple times over but with these languages it is rarely about the languages themselves but their ecosystems: https://cran.r-project.org/web/packages/available_packages_b... To go from R to Julia, as an example, one would have to give up on a hundred or so high-quality packages potentially related to their activities.

Having looked at a large number of R packages source code, I do hesitate to freely label R packages as generally high-quality. I’ve been operating on the “trust, but verify” principle

Re: My Journey from R to Julia

#46

Post by getoffmycase »

aljabadi wrote: post #4

It’s important to note that R’s S4 Object System now supports multiple dispatch & I have enjoyed using it. I would agree that it’s not quite as elegant as Julia’s. See https://www.mpjon.es/2021/05/31/r-julia-multiple-dispatch/

The problem with S4 is that it really sucks to write.

Re: My Journey from R to Julia

#47

Post by naijaboiler »

em500 wrote: post #9
_Wintermute wrote: post #3

Earlier quoted context omitted.

It's a really sticky misconception. I've seen many beginners telling others to "never ever use loops in R", and so you end up with nested sapply()s or whatever soon-to-be-deprecated tidyverse functions are in vogue that nobody can reason about.

So Rob Pike’s rule 1 and 2 again: Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. https://users.ece.utexas.edu/~adnan/pike.htm…

Avoid the allure of premature optimization

Re: My Journey from R to Julia

#48

Post by BrandonS113 »

harshreality wrote: post #44
BrandonS113 wrote: post #33

Earlier quoted context omitted.

No, nlopt. Why we could easy port from R to Julia as nlopt exists for both (its c)

If you use the same native C library from both Julia and some other language, and (presumably) that library is where the algorithm spends the vast majority of its time, why would you expect Julia to be faster?

no. the code spends 99% of its time in 5 lines in the objective function. And my usual experience is that Julia is much faster than R. Just not always, apparently.

Re: My Journey from R to Julia

#49

Post by moelf »

sfpotter wrote: post #11
hnarayanan wrote: post #7

I get confused by this every time this comes up. Is multiple dispatch the same as function-overloading (e.g. in C++)?

They're different. IIRC, multiple dispatch is dynamic (i.e., happens at runtime) while C++'s function overloading is static (happens at compile time).

>happens at runtime

is not technically true, because that implies a massive slow-down. instead it's more accurate to say behavior-wise it's always equivalent to a dynamic dispatch, but because Julia's Just-Ahead-of-Time compilation, often you eliminate the dynamic dispatch during run time.

Re: My Journey from R to Julia

#50

Post by BrandonS113 »

ChrisRackauckas wrote: post #43
BrandonS113 wrote: post #33

Earlier quoted context omitted.

No, nlopt. Why we could easy port from R to Julia as nlopt exists for both (its c)

Ahh then it's all based on the speed of the objective function and the gradient calculation code. Do you have an example to look at for that? Or did you try modelingtoolkitizing and running an auto-simplified form?

Yes, well no gradients. It a simple parametric function (6 parameters) applied to a vector of lengths 10 to 20. All vectorizes in the language of R. All powers, logs, exponentials, ratios, and sums. Large number of local maxima, and places where function cannot be evaluated. So probabilistic optimizer is very important.

Come to think of it, for this sort of calculations, R and Julia should take the same time.

Post reply on HN