61–70 of 120 posts
I work with PhD chemists at a F500 company, most everyone uses Python, we have a pocket of users that are on the R train. Mostly Rstudio mixed with Python. Someone just asked to install Julia on the compute cluster just last week so we'll see how many others start using it.
Earlier quoted context omitted.
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.
One of the reasons why Mark Godbolt created compiler explorer was to prove teammates that what for them was pretty obvious actually wasn't.
Earlier quoted context omitted.
I only used Julia for a short time, but I didn't see the blazing fast speeds I was promised. I've seen the benchmarks, of course, on which the claims are founded, but the C-like speeds weren't obvious to me in everyday data science workflows. In the end, there wasn't sufficient motivation for me to switch to Julia as my weapon of choice. I do like Pluto[0], though... [0] https://plutojl.org/
You need to know how the compiler propagates types in detail to write performant code. It is quite hard.
If you leave them off you can make a function generic but you need to make sure you don't have multiple returns that could each return different types.
Earlier quoted context omitted.
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.
But if you are combining multiple operations on a vector, there could be opportunities for Julia, in-place operations, fusing, simd. Maybe even StaticArrays.
Any chance of sharing that little piece of code?
Julia is the new R for me. Unless R re-invents itself.
Earlier quoted context omitted.
One of the reasons why Mark Godbolt created compiler explorer was to prove teammates that what for them was pretty obvious actually wasn't.
There's a reason Godbolt was made for C/C++ rather than python/R. In a fast language you need to know what the compiler is doing to know what's slow. In a slow language, the slow part is pretty much always just "code that does anything in the language".
This is a pretty weak article. The author lists five reasons an epidemiologist would be interested in Julia and then only gives a (kind of simple and contrived) example for one of them.
> 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/
[1] Vectorization is more than ten times faster than the naive loop.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.
You don't have to. Just use Rcall. Of course R has been here longer. Eleven years after its creation, R had fewer than 500 packages. Julia was released in 2012 and today has over 7,000 packages.
R
Cited in: 8,589 Publications
7,353 [Citing Publications in] Statistics (62-XX)
https://zbmath.org/software/771
Julia
Cited in: 442 Publications
64 [Citing Publications in] Statistics (62-XX)
https://zbmath.org/software/13986Earlier quoted context omitted.
There's a reason Godbolt was made for C/C++ rather than python/R. In a fast language you need to know what the compiler is doing to know what's slow. In a slow language, the slow part is pretty much always just "code that does anything in the language".
Python is only slow because so far there has been a huge disregard for JIT implementations, versus how other dynamic languages have decided to deal with perfomance issues.