Julia vs R vs Python

performance

#41

Python is great , Julia is great , Matlab is great
give it a rest guys will ya


#42

Numba has some semi-recent functionality for “jit classes” to work around this limitation but as I understand it this requires more work on the user’s part, and I don’t think it’s very widely used.


#43

Even these are required to be heap-allocated, as I understand it, which prevents them from being stored efficiently in arrays etcetera; in that sense, they are analogous to mutable struct in Julia.


#44

Would be interesting to see if https://github.com/python/performance/blob/master/performance/benchmarks/bm_chaos.py could be Numbad (and then compared to the julia version at https://github.com/JuliaCI/BaseBenchmarks.jl/pull/92).


#45

I think these discussions are much more productive when they’re framed as “for which tasks, and by which users, and by what criteria, is language X really good”, rather than “is language X or language Y better”.

Or, perhaps equivalently, “who would benefit from using language X instead of language Y, how, and why”.


#46

Yes, very true.
Also, comparing languages can be productive if you ask yourself what lessons learned in other languages can be applied to the language you care about (not to say that all can be).
That can be especially useful in Julia, since unlike most languages I’ve dealt with outside of the Lisp family, a lot of Julia’s design / evolution come from the user community, instead of a single dictator or very small core.


#47

r3tex, I think you should compare Julia with PyPy (not CPython) because both of them uses JIT. Comparing Julia with scripting language without JIT implementation is just not fair. Julia uses JIT. It makes Julia faster, but memory consumption increases.


#48

You know, I would if PyPy were a drop-in replacement for CPython… but it’s not, and even with numba the runtime crashes because vectorization exhausts memory. But that’s not the point. You can jump through hoops in any language to get speedups, but the best part about Julia is that you can take pseudocode for some algorithm, copy it, and almost always get good performance.


#49

… and if not, you can do the optimization in Julia, solving the two-language problem [video].


#50

I think Julia is more AOT than JIT, isn’t it?


#51

Probably Just In Time AOT.


#52

:smile: I think that Julia’s model is an innovation (and thus an outlier) among programming languages, and it will take a while for terminology to catch up.


#53

I’m aware it’s off topic, but I think we should pick one acronym :slight_smile:

Personally, I really like Just Ahead Of Time. There even is a blog post explaining why Just Ahead Of Time is much better than Just In Time, though it doesn’t seem to be about compilers.


#54

I think that’s awesome.


#55

Yes! There is real marketing value here in grounding people’s priors to be different than expecting a typical JIT.

While I was at first irritated by long compilation times in Julia, I realized that if you think of what is really going on behind the scenes, the correct comparison is to compiling C++ with heavy template meta-programming. Under that comparison, Julia looks pretty good.


#56

Yeah. I think that, once I realized that in many cases I was getting faster than C++ code, I started thinking about it as though I’m programming in easy C, instead of fast Python. In that sense, “easy C++”'s productivity is pretty amazing :smile:.

I know we want to appeal to Python users because that’s a much bigger pool, but for people who would be writing big scientific computing simulations in C or Fortran, Julia is just… the future. It’s a huge difference.


#57

Also, good luck understanding seriously template-heavy metaprogramming in C++ when reading the code 3 months later :smile:


#58

In R if you want speed you should use data.table.


#59

I definitely want speed, and I’d be very interested if you could provide an example of how the algorithm might be implemented using data.table. At first glance the syntax seems very counterintuitive and restrictive.


#60

Actually data.table “broke” the whole design of R’s copy-on-modify by providing “inplace” assignment and reassignment of columns without replacing the whole data.frame. At first its syntax is confusing but you can get used to it. Also you can use dtplyr to apply dplyr syntax on top…

I realise this is a Julia forum. Anyway I have even more respect for the data.table crew now that I have tried to write data algorithms in Julia that tries to match and/or beat them in performance. They have generally the fastest algorithm in the r/python/Julia-verse. Even though Julia is meant to be faster some of their C implementations are hard to beat.