Hacker News Reader

Comment by IshKebab | Hacker News Reader

What do you use instead though? Octave is very slow, Julia is even slower and Numpy has an annoyingly verbose syntax because it has to be valid Python.

Additionally I've not found a plotting solution that is as robust and fast as MATLAB.

MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.

View on HN

> Julia is even slower

Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..

Well written Julia should definitely be faster in most cases unless Matlab is using a specific well performing algorithm that Julia doesn't have built-in.

With that being said, there are a lot of Julia posts on the subreddit or stack overflow that go like "Why is this Julia code 10x slower than my Python code"? One issue is that getting good performance out of Julia isn't always obvious without a pretty good understanding of how it works. Thankfully, people are willing to help you tweak your code to make it much faster.

They should be similar if they both rely on standard LLVM optimizations. I assume both have their own optimization passes on some mid-level IR but I personally don’t know whether one or the other has any particular language features that dramatically improve performance over the other. I’d like to hear more!

I was just saying that getting really good performance out of LLVM with Julia isn't always obvious. This isn't just a Julia thing. People starting with Python + Numpy have issues with speed when they don't take advantage of the vector primitives and drop into regular Python loops for part of the code. First time Haskell users are frequently confused when it is significantly slower to parse text than Perl as one of the default string libraries is really slow and not recommended even though it is what a new user would think should be the first choice.

Overall I'm excited for Julia, but have a lot to learn. As far as Octave/Scilab type applications go, I find them useful for small systems where I need to make sure the math of what I'm doing is correct before writing it in something like Julia or Python + Numpy. Excel is also surprisingly good for the really simple stuff (Ex: inverting a small matrix and doing some matrix multiplications).

I assume they're referring to cases like this [1].

A few years ago I think there were some performance regressions in Julia relative to JIT'd Python (which, using LLVM like Julia, is way faster than normal Python). This seems to be mostly fixed now.

In the example above, the OP was getting 2ms in Numba vs 8ms in Julia three years ago, and recommendations from Julia folks were able to get the latter down to parity with an equivalent algorithm or 386us with an improved algorithm.

On my laptop today, I seem to get 2.0ms in Numba, 2.7ms with Julia 1.0, and 80us using the improved algorithm in Julia 1.0 (and, just to drive home the importance of compilation, 780ms in Python without Numba).

[1] https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_l...

It may execute faster when it finally gets around to it. But just loading the plotting library (Gadfly) takes over 10 seconds!

https://github.com/JuliaLang/julia/issues/4373

Starting all of Matlab never took that long.

I don't know what version of MATLAB you're using :P. They definitely have their logo screen open for a minute or two before the program shows up. That's quite a long load time. They just made it pretty.

Have you tried under julia 1.1? Latency issues much better, and will only improve.

R is nice for stats stuff, even if performance can be iffy for certain tasks. The existing libraries for basic ML tasks are largely fantastic. The syntax rubs many people (including me) the wrong way. But I don't like the paradigm for basic ML tasks in scikit-learn (python) much better.

Anything involving matrix computation is great to do in python because of existing libraries (numpy). I think most people who are actually writing code (i.e. grad students) don't mind the syntax because they learned it in school starting in undergrad.

Octave's main appeal to me (and most people I work with) is being able to run existing MATLAB code. However, making it work for nontrivial MATLAB projects, is, well, nontrivial. It's also very slow.

Julia is the language I'm most excited about. It's fast [1] even though it has a slow startup time, and that's improving quickly. It's got a nice grammar-of-graphics-based plotting library [2] that's quickly catching up to R's ggplot2. I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I like the syntax a lot, too. The data types take some getting used to, not unlike R. I also think if Julia moves away from JIT compilation, it has potential to be the language of choice for deployed NN models (right now, that's C++).

As for plotting, R's ggplot2 beats MATLAB any day of the week for me. To each his own.

[1] https://julialang.org/benchmarks/

[2] https://github.com/GiovineItalia/Gadfly.jl

> I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future).

I think it will overtake python for NNet stuff also: https://julialang.org/blog/2018/12/ml-language-compiler

Reply on news.ycombinator.com