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

31–40 of 120 posts

Re: My Journey from R to Julia

#31

Post by pxmpxm »

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…

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.

Re: My Journey from R to Julia

#32

Post by [deleted] »

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.

[deleted]

Re: My Journey from R to Julia

#33

Post by BrandonS113 »

ChrisRackauckas wrote: post #30
BrandonS113 wrote: post #8

Just now I was thinking of moving a long calculation from R to Julia (non-linear optimisation of a simple function with multiple local minima, for a lot of different datasets). No loops. Embarrassingly parallel. And to my great surprise, R and Julia took the same time.

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)

Re: My Journey from R to Julia

#34

Post by usgroup »

TLDR: Author switched to Julia because he “fell in love” with it, with no further qualification.

He then speaks a bit about multiple dispatch and how it’s useful when it’s suitable.

Personally I saw nothing here that might actually convince someone to switch. R + Tidyverse + Rcpp + CRAN is formidable.

Re: My Journey from R to Julia

#35

Post by mxkopy »

From my understanding Julia is closer to metal than R. This means the semantics are much more specific than R, and the syntax is more consistent/rigid.

For example, plotting in R always baffled me.

plot(x, y, col=..., col.name=...)

In this case, col.name is literally just a symbol. But in another context col.name is the data with index 'name' stored in col. Or something, it's been a while.

R seems to have a lot of these 'special contexts' that A. make understanding and writing code much quicker and B. reward familiarity over intuition. One line in R can be 100 in Julia, and both compile to 80 machine instructions, for example.

I'd say if you can agree with others on what R code does and you're comfortable with R, then use R. If you need to build something performant with many domains, then Julia is a great language for that sort of thing.

Re: My Journey from R to Julia

#37

Post by sfpotter »

borodi wrote: post #22
sfpotter wrote: post #11

Earlier quoted context omitted.

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

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

Re: My Journey from R to Julia

#38

Post by vharuck »

_Wintermute wrote: post #3
karencarits wrote: post #2

> For example, in R, we try to avoid loops because they are very inefficient This was true before, but the performance of for loops has been improved a lot later years, and while vectorization is still faster, for loops are no longer a no-no See https://www.r-bloggers.com/2022/02/avoid-loops-in-r-really/

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.

Agreed. The most common reason loops become bottlenecks is people "adding onto" vectors or dataframes. This causes a whole new vector to be created, the data from the old one copied into it, and then the new data filled in at the end. You'll rarely notice the performance hit unless you stick it in a loop that runs tens of thousands of times.

For those who want to avoid it and still use a loop, you can create a vector beforehand with the final length and fill it in. If you don't know the final length, create a vector with a good guess for length, double its length whenever it gets full, and then crop off the unused tail when you're done.

Re: My Journey from R to Julia

#40

Post by johnmyleswhite »

karencarits wrote: post #2

> For example, in R, we try to avoid loops because they are very inefficient This was true before, but the performance of for loops has been improved a lot later years, and while vectorization is still faster, for loops are no longer a no-no See https://www.r-bloggers.com/2022/02/avoid-loops-in-r-really/

Does the article you linked not show that a loop is 10x slower than vectorization for computing square roots? The fact that 10x is better than the 60x slowdown for vapply isn't really evidence that loops are a reasonable alternative to vectorization yet.
Post reply on HN