The Julia Programming Language | Hacker News Reader

The Julia Programming Language

medium.com

66 pointsbauta-steen35 comments

Julia and Matlab use the same (Fortran-based) linear algebra codes in the background.

I think it is great to see that a port of the Fortran code in Julia is nearly as fast as the Fortran code itself. So you can take Julia and write concise Matlab-style code (vectorized everywhere) or write imperative code (loops everywhere) and be equally fast.

Note that the graphs in the post are biased. The Fortran version uses a different algorithm for the solver.

Edit: The Matlab code is highly obfuscated. That is not good for the sake of comparison.

https://github.com/precisesimulation/julia-matlab-fortran-fe...

Except Julia vectorised is not as fast as Julia looped.

so this :

    for i = 1:size(a)[1]
        a[i] = 2a[i] + 3b[i]
    end

is faster than

    a = 2a .+ 3b

(although I haven't benchmarked it)

Here's someone that did : http://aflyax.github.io/de_vectorization-runtime/

but in 0.5 there are speedups, apparently.

Here's a stack overflow discussion on it

http://stackoverflow.com/questions/27928502/julia-vectorized...

Very interesting, just tested on 0.5 and vectorized can still be a magnitude slower.

ulia> @time vect(x, y, a, b) 0.000038 seconds (29 allocations: 37.406 KB) 1×2 Array{Float64,2}:

julia> @time devect(x, y, a, b) 0.000006 seconds (10 allocations: 512 bytes) 1×2 Array{Float64,2}:

julia> @time vect(x, y, a, b) 0.002324 seconds (73 allocations: 3.075 MB) 416×2 Array{Float64,2}:

julia> @time devect(x, y, a, b) 0.000206 seconds (18 allocations: 23.359 KB) 416×2 Array{Float64,2}:

Matlab uses mkl for linear algebra, not the old school Fortran reference routines.

Optionally. OpenBLAS and LAPACK are the default.

See here: https://github.com/JuliaLang/julia

  OpenBLAS — fast, open, and maintained basic linear algebra subprograms (BLAS) library, based on Kazushige Goto's famous GotoBLAS.

  LAPACK (>= 3.5) — library of linear algebra routines for solving systems of simultaneous linear equations, least-squares solutions of linear systems of equations, eigenvalue problems, and singular value problems.

  MKL (optional) – OpenBLAS and LAPACK may be replaced by Intel's MKL library

I have compiled Julia from source several times thx; my point was that MATLAB is not using reference Fortran routines.

Sorry for being old and still living in the Python world: I would like to see an additional benchmark for this based on Python+Numba.

Found this, and Python numpy compiled with MKL or using numba does quite well: https://www.scivision.co/speed-of-matlab-vs-python-numpy-num...

I do not understand the notion of a fast language. I can buy the idea that a compiled (or JITted) language will run loops faster than an interpreted one. But writing a DGEMM in Julia or in Fortran is not what will make it fast, it's careful performance profiling and machine-specific optimizations that will do this. Apparently every language community has to learn this the hard way once it gets mature enough. See the following for an example from the C++ world: https://youtu.be/hfn0BVOegac?t=30m40s.

The explanation is simply that people are happy to get a 10x speedup even if 100x is possible in theory.

Python + NumPy has a large mindshare, and can be 10x from Fortran/Julia even if you use NumPy vectorization. And often loops are simpler or required anyway (dropping Python to 1000x slower).

Languages like Julia and Fortran also allows you to hit peak where you are limited by memory bandwidth, which is most of the time (not for DGEMM though...)

Some languages are explicitly designed to be easier to optimize than others. Both for their compiler and, most importantly, their users.

The mythical Sufficiently Smart Compiler, is, well, a myth.

Does anyone here know any good debugger for Julia?

That being said, Julia is really fun language to learn if you know Python and Matlab already. Although in the beginning, I kept on forgetting whether it is following Matlab-like syntax or Python-like syntax for certain features.

One of the biggest problems that I had with Julia (which is one of the main reason I stopped using it) was the flexibility of the . notation. I use this feature in Python and Matlab a lot and I had some serious trouble trying to make it work or finding examples on how to use it. Though I think this problem will be fixed as the community grows.

https://github.com/Keno/Gallium.jl for the debugger. It was still a bit unstable last time I tried it.

What are you referring to? Properties?

I mean the composite types that Julia offers. I was originally trying to use it to replicate some of the structure array that Matlab offers. Understandably this isn't the most efficient way to create a list, but it makes it so easy and clean to pass variables between functions when I'm trying to crunch some numbers quick. I tried getting used to calling sub-functions with a . (like Python) as well but didn't get too far.

I'm intrigued, could you give an example of the Matlab way?

Most of MATLAB toolboxes and functions send most of their data between function this way. For instance, the GUIDE toolbox puts everything between handle functions and structure variables. If you wanted the button to look a certain way, all the information can be stored in one variable. For example (this is just an dummy example, I can't recall the exact syntax right now for GUIDE), the button variable will be: button1.color = 'blue', button1.size= [150,200], button1.position = [200,325], etc... Therefore when you only need to input and return one variable (Button1) for each element. It's a really convenient way to keep track of your variables.

Interesting. Maybe dictionaries would fill that role? Julia has macros, so you can usually implement other languages' syntactic convenience.

I find it almost purely Matlab-like in syntax. What do you have in mind that's Python-like?

I think Julias adoption is hindered by the lack of a real Julia-IDE aimed at data analysis. R has R-Studio, Python has Spyder, both of which are excellent nowadays. Julia has Juno in principle, but setup has never worked for me on multiple machines. The Julia language has a lot to offer, but there is no convenient way for people to give it a try that is comparable to what they have grown to expect from competing languages.

There's actually Jupyter. Then there's a julia backend for ess as well.

I'm using R regularly, and I couldn't care less for R-Studio. In our stat group, only 1 statistician out of 7 is using R-studio, while all of them are using R.

The IDE has very little to do with adoption.

There can be a difference between IDE choice among professionals and the role of an IDE in introducing people to the ecosystem. On ramps don't start at the target elevation.

For what I see, the first and foremost initiating factor for a statistical package is education, and second it's available methods/packages. You have universities where you can clearly see that the predominant taught package is Stata, or R (and in the latter, the choice of UI is mostly arbitrary).

In the end though, unless you want to reimplement methods, you can count on having R packages for any method you can think of.

Few statisticians though spend the time to evaluate different IDEs than what they where taught. I've "converted" many still using Rwin.

Try Juno (a Julia IDE on top of Atom): http://junolab.org/

Recent JuliaCon talk allowing off the debugging features. https://m.youtube.com/watch?v=yDwUL3aRSRc

Matlab delegates a lot of heavy lifting to native routines like MKL and otherwise has a JIT for user code. For workloads which fit on a single workstation, it's usually a reasonable performer, for a lot less effort than the alternatives.

That said it costs too much and doesn't scale well to multimachine workloads. The language is also quite quirky by modern standards.

Are you saying that Matlab is "a lot less effort" than Julia or NumPy? (Assuming cases where these alternatives have the functionality in toolbox of course)

yes (?)

It's probably (n^3 * n^2) vs (n^2 * n^2) , and not cubic vs linear as was stated, where (n = 1/h).

I've been curious for a long time why, despite the claims that Julia is so fast for scientific computing, no one has actually provided any Julia implementations for all the scientific and number-crunching problems over at the popular benchmarks game [0]. It would seem to me a great place to advertise the language's speed, so no news is curious news there.

[0] http://benchmarksgame.alioth.debian.org/

See https://github.com/JuliaLang/julia/tree/master/test/perf/sho...

http://benchmarksgame.alioth.debian.org/play.html#languagex

Having been disappointed with the performance of Octave and Python as Matlab alternatives, Julia looks very compelling. Is anyone aware of any thorns to watch out for?

Do you have specific concerns? What kind of project would you like to do? Julia is nearly as convenient as Python, and can be nearly as fast as Fortran, but it has neither the polish or large community/library of those languages.

I'm usually concerned with how easy it is to manipulate text: sort, search, delimit, and replace substrings. Especially given an array or matrix of string data.

Matlab is in part a wonderful IDE that lets me run any segment of code and maintain variables. This is perhaps outside of the language, but I did see Julia's blog post about Juno and it looks useful.

Maybe the biggest concern is documentation for functions. Is it quick to look up any function? Is it quick to discover available functions relevant to a task?

> I'm usually concerned with how easy it is to manipulate text: sort, search, delimit, and replace substrings. Especially given an array or matrix of string data.

No significant experience there. I would read http://docs.julialang.org/en/release-0.5/manual/strings/ and make sure that the data structures are adequate for your work. You can write C-like code and get C-like performance. Julia also makes it easy and efficient to pass data to and from C. Python/R/Matlab interop works nicely, but there's a cost.

> Maybe the biggest concern is documentation for functions. Is it quick to look up any function? Is it quick to discover available functions relevant to a task?

The docs are pretty terse:

http://docs.julialang.org/en/release-0.5/stdlib/strings/

Google is pretty good for discovery, although not as good as for widely-used languages. Many people ask on the julia-users Google group, and almost every well-written question gets answered. Typing ?function_name in the REPL returns the function docstring, similar to Python, and does a (very-limited) look-up.

I use Jupyter, and find the experience much better than in a REPL. I've tried Juno, and it's still too much of a WIP for me. YMMV.

This benchmark is rubbish, and the author doesn't know what he is talking about. "Knowing a little about Matlab should really be surprised to see that it performed just as fast as Julia and Fortran. This is due to the heavily vectorized and optimized Matlab assembly routine. "

Complete gibberish. Matlab (like Octave and the parts of Julia tested here) is made of Fortran parts. Were this an actual benchmark it would have spectacularly outperformed Matlab, Octave and Julia.

Reply on news.ycombinator.com