Except in practice, to write fast Matlab code you need very deep understanding of Matlab’s internals and years of experience. Seemingly trivial patterns end up slowing your code down by multiple orders of magnitude, and there’s more “guess and check” involved when trying to write code that can be effectively JIT compiled by Matlab than careful reasoning. Even worse, the JIT and the profiler don’t get along, so it’s often impossible to get any insight into the reasons for JIT-related performance differences.

In general, Matlab is an extremely unpleasant and frustrating environment compared to almost any other language I’ve worked with. The only thing Matlab has on Python/Numpy is a nice quantity of publicly available code for various technical functions. Most of this code is hacky academic prototype stuff, but that’s much better than nothing if you’re trying to follow someone’s algorithm written up in a paper.

The Matlab GUI and tooling is a buggy and unpolished Java turd from the 90s which fits in poorly with any modern operating system.

And yet every time I try to get Matlab users to use something else (Python or Julia) the one thing they almost immediately complain about is the lack of a GUI IDE as good as the Matlab one.

Pycharm[0] has become my prefered Python IDE about 2 years ago (when they went free commmunity/pay for pro) and it's a way better environment than MATLAB. It now has "Scientific tools" too[1], and I understand some good features, though I haven't used them yet.

The only good thing I still recognize of MATLAB is that most toolboxes work together without (too much?) hacking. Working with Python/NumPy you eventually find stuff that you need to adjust to work with that other library you just found implements that thing you absolutely need.

[0] https://www.jetbrains.com/pycharm/

[1] https://www.jetbrains.com/pycharm/features/scientific_tools....

Spyder offers a similar environment. It has a variable explorer, script editor, console, etc all in one window (which I think is what matlab users are looking for).

It's still pretty immature, but promising.

That said, matlab's linear algebra syntax is still better than python's.

In practice you can't rely on the compiler, because you don't know what the compiler is doing.

You certainly can't assume it's going to make the smartest possible decision for all of your code. There's no standardisation for optimisations, and they're often a context-dependent trade-off anyway.

The only way to write fast code is to learn the quirks of the tool chain and profile production binaries to find the bottlenecks.

EDIT Also in the scientific fields I've encountered not using the various libraries like numpy is non-idomatic. I personally think that python should absorb numpy into the standard library but effectively people I know treat it as if it were already there.

You can argue that numpy etc are implemented in C. But is the Julia interpretor not implemented in C?

Most of the Julia standard library is implemented in Julia.

Arguments about liking to loop over arrays to operate on them are a matter of taste. I like whole array operations, it's just what I learned first and best (Fortran 9x+ and numpy). Someone else may prefer to write loops (maybe they started doing numerical work with F77 or C). There is no universal correct way to express things -- but there is sometimes a language specific best way and to benchmark ignoring this is not good.

Reimplementing LAPACK or BLAS would be a lot of unnecessary work, but I think that one goal of the language is to be fast enough that a reimplementation would not be worse than the existing versions. (I'm not affiliated w/ the project, though, so I'm just guessing.)

[1]: https://github.com/JuliaLang/julia/blob/master/base/arraymat...

https://lists.swift.org/pipermail/swift-evolution-announce/2...

I don't have much to offer to Julia on technical terms. Octave's codebase started as pre-standard C++, and it's been a long and arduous job to very slowly modernise it. Julia has the advantage of starting modern.

I think the biggest lesson I've learned is, don't underestimate Matlab. It may be old, it may be an ugly language, but it also is gigantic, very well-funded, and everywhere. Julia and Octave are approaching Matlab from different angles, Julia by providing a better language and Octave by providing a free drop-in replacement, but ultimately we are both trying to replace Matlab.

Matlab users greatly value having a complete package with an editor, debugger, visualiser, profiler, and system modeller all in one. They don't generally see Simulink or the symbolic toolbox as being separate components, or indeed, as the completely separate programs that they really are. For the devout Matlab users, these conveniences greatly outweigh a better programming language. Going further, many Matlab users don't even consider their activity "programming" at all, and in recent years Matlab even writes the code for you if you just push a few buttons.

We're seeing some academics slowly switching over to Julia. This is great. The Mathworks knows very well that captivating young, malleable minds in university is how you get loyal paying customers, namely, the future bosses of these newly-molded minds. Julia is doing a good job appealing to profs. I am optimistic that within five years or so, new generations of Julia-trained graduates will slowly spread the love of the new language.

That's a very good point. Julia's debugger and profiler are both horrifyingly bad.

https://groups.google.com/forum/#!topic/julia-dev/-LTsBVRv1d...

You figure out who's who.

I was merely trying to understand why thebooktocome thought the profiler was so bad.

Have a nice day.

Also your words with the easy usage of "stupid" led me - wrongly! - into the direction that you might not be interested in understanding why users prefer Matlab, but more in expressing your opinion about the topic.

And to be frank, again perhaps due to my weak understanding of English, your usage of "You figure out who's who." and "Have a nice day" to me do not sound as the intention of trying to understand things but more on making clever remarks. But as I've pointed out, this might be due to the fact that English is not my native tongue.

In my experience (15 years), Matlab has been the best for exploratory data analysis. If you change a script, you don't need to worry about re-importing issues like in python; you can even change code DURING a debugging session, EVEN with GUIs. I have been using python+numpy+pandas for a few years now, and python just feels like there is an impedance there that I don't get from Matlab, primarily with graphics/matplotlib. But, deploying and sharing python is easier. I admit it could just be my experience with Matlab that biases me. I usually find that people bitching about Matlab don't like the language, and that is usually because they are viewing Matlab AS the language (like python), and not as a data exploration and analysis environment.

Relevant to the topic at hand, Julia does have that functionality already, and it in fact (afaik) uses the same engine that's behind iPython, the Jupyter environment. There's even a web-based community version for people to try stuff out: https://www.juliabox.org/

If you mean a packaged script more like a mathematica notebook, I don't believe so.

Let me just clear one thing: I am not trying to represent Julia in any way. I wouldn't be legitimate for that at all. I tried to not write anything negative about the Julia language. Let me know if you think i did, in which case I'll modify my text.

To your point about compilers in charge of speeding up code, I see Numba doing more and more. I hope it will cover all of Python soon.

I think the flaw in the article is when it switches to answering, "did the Julia team [write] Python benchmarks the best way for Python?" Then it rewrites the fib implementation to use a cache, which makes the comparison to the julia version completely ridiculous. It also does all sorts of optimization which clearly deviated from the spirit of the benchmark, naive python vs naive julia.

I wish the conclusion had been written in a way that clearly answered the original premise, should we ditch python for julia? The article clearly showed that there are a lot of good ways to speed up python code. Looking for algorithmic complexity wins (like in the fib example), using cpython, using numba, and profiling all can be used to speed up python code to the level of naive julia code. Which leads to the conclusion, if all you want is faster code there is no need to ditch python for julia.

I made it clear however that I was going to answer a different question: did the Julia team wrote Python benchmarks the best way for Python?

That's all what the post is about: how to run Python code faster.

I will need way more Julia experience to be able to even think about answering the first question. The only thing I am 100% sure is that these micro benchmarks do not help answering that question.

But in general, unrolling loops, caching (some) results, and eliding redundant code rightfully is the compiler's job. That's a different kind of speedup.

I pretty strongly disagree that with the meta-parent that it's the "compiler's job to speed up your code". It just doesn't have enough context to be able to do it effectively. I would actually prefer a predictable compiler to one that tries to do all sorts of magic tricks that can be perturbed by seemingly trivial code changes.

That's not what jordigh is talking about. Let's say you figured out a clever way to get your problem to O(log n). That's definitely your job. But in practice, constants matter - that is, 10 log n is way, way worse in practice than 2 log n, even though they are both O(log n). And that's the kind of optimization that compilers may be better at than you. Once you have convinced yourself that the performance of some component matters, a good principle is to figure out the best complexity class you can (using the "right" data structures and algorithms), then write the most idiomatic code possible.

Therein lies your problem. If I took some of my python code and literally translated it to Julia would it run like a pig as well? Could I even do a literal translation?

Julia's like scientific Python, but where the naïve implementation also runs fast. "Fast by default.", perhaps.

"type unstable", IO and text processing code is also slower.