
Why I’m not on the Julia bandwagon (yet) (2012) - hk__2
http://wesmckinney.com/blog/?p=475
======
x0x0
Julia has a lot of rough edges. For example, the dataframe support is
primitive. Type issues show up all over the place; for example, if you extract
a column from a dataframe, then combine it with other columns via [], it
sometimes fails if the column you extracted is first and succeeds otherwise.
Saving matrices is still really primitive; nowhere near as good as R or
matlab. In julia, you still have to remember what you put in the file and how
big it is.

Nonetheless, julia is _awesome_ and if you haven't tried it you're missing
out. It's pleasant to work in in a way that numpy + python isn't. It's a
higher performance R, one which has a hope of scaling to the sizes of data I
want to use. You can almost always write in matrix notation then decay to
loops if necessary.

a toy irls implementation looks like:

    
    
       sigma = function(X)
          1/(1 + exp(-X*beta))
       end
    
       beta = zeros( size(X,2) );
       max_iter = 50
       iter = 0
       converged = false
       while iter < max_iter && ~converged
         s = sigma(X);
         cost = sum(Y .* log(s) + (1 - Y).*log(1 - s));
         grad = X' * (s - Y);
         H = X' * diagm( s .* (1-s) ) * X;
         d = H\-grad;
         # print([beta d])
         beta_new = beta + d;
         delta = norm(beta_new - beta);
         beta = beta_new;  # NB: exact hessian so no line search
         @printf("iter: %d; beta delta %f log like %f\n", iter, delta, cost)
         iter += 1
         if delta < 1e-4 converged = true end
       end
       
       beta
    
    

If you haven't tried it and you're an R or numpy user, you should give it a
try immediately. Lots of people seems to use ipython or ipython in the browser
to efficiently use the repl with code. I prefer tmux with 2 windows; vim in
the left, julia in the right, and vim-slime to move code over.

------
jamesjporter
FWIW, running Wes' code with a fresh pull of Julia today shows some
improvement in the pure-Julia benchmarks at least:

    
    
        Array operations took 79.55683398 ms
        inner took 23.88444026 ms
    
        BLAS took 48.182116560000004ms
    

Obviously its possible that this is just due to differences between our
machines; just figured I'd throw it out there.

------
eliteraspberrie
In most cases I've come across (signals processing) a trivial Python (NumPy)
implementation was much faster than a trivial Julia implementation, because of
the vector syntax. This, IMHO, is the Achilles heel of the Julia language.

Generally speaking, any language for numerical computing _must_ feature vector
syntax. Most numerical algorithms work on arrays (vectors, matrices, and so
on) and can be easily translated into a language which supports vector
notation: MATLAB, Fortran, and Python (NumPy).

Asking people, in 2013, to explicitly write loops in numerical code is a
definite step backwards.

~~~
nick_dm
Is there any thing in particular that Julia is missing here?

[http://docs.julialang.org/en/release-0.2/manual/arrays/#vect...](http://docs.julialang.org/en/release-0.2/manual/arrays/#vectorized-
operators-and-functions)

[http://docs.julialang.org/en/release-0.2/manual/linear-
algeb...](http://docs.julialang.org/en/release-0.2/manual/linear-
algebra/#elementary-operations)

My understanding was that Julia gives you the option to write loops explicitly
but it doesn't stop you using vector and matrix operations when appropriate,
so I'm curious if there are any particular operations that its array
implementation are missing?

~~~
micro2588
I think this comment is referencing the fact that as of right now, slicing a
julia array creates a copy and not a lightweight "view" of the sliced data.
This makes vectorized operations on slices of arrays sometimes faster in numpy
than in julia. See
[https://github.com/JuliaLang/julia/issues/3701](https://github.com/JuliaLang/julia/issues/3701).

~~~
StefanKarpinski
Note that you already can make view slices, it just isn't the default. As per
the issue you linked to, the default will change to views in version 0.3.

------
rrrrtttt
No matter which language you use, you will not beat Intel MKL because that
code is optimized by Intel specifically for each architecture. Precisely
because automatic optimization by compilers is not good enough. These
comparisons are completely irrelevant. Incidentally, this also shows why
pursuing the goal of a "fast" numerical computing language is a waste of time:
the speed derives from using the appropriate hardware vendor libraries, not
from the language runtime.

~~~
egocodedinsol
I'm confused: Matlab uses MKL, Armadillo can be configured to work with MKL if
you have it, and Julia supports MKL, and NumPy too. So if everything uses the
same hardware vendor libraries, I'm not sure if that's where your actual
speedup will come from. Also, MKL syntax itself is not particularly fun
compared with Matlab/NumPy/Julia/etc.

~~~
rrrrtttt
Once your language allows you to use MKL and its equivalents, your code will
use every arithmetic unit of the CPU in almost every cycle and therefore
performance-wise there is no difference which language it is. So it's all down
to which language offers you better library support and nicer syntax.

~~~
egocodedinsol
Hmm. If it we're true that speed is independent from language once mkl is
installed, wouldn't you expect there to be no observed performance
differences? And yet there are large measurable ones for reasonable tasks even
with mkl.

------
msl09
This feels almost like a parody to [http://calculist.org/blog/2013/11/27/on-
on-asm-js/](http://calculist.org/blog/2013/11/27/on-on-asm-js/)

~~~
GhotiFish
seems odd to parady a starry eyed wishful thinking post with a negative
pessimistic post.

Are you referring to this article? [http://acko.net/blog/on-
asmjs/](http://acko.net/blog/on-asmjs/) Because this article is awesome

