Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of Matlab Code

runmat.org

Post reply on HN
Print view View original

101–110 of 174 posts

Re: In Defense of Matlab Code

#101

Post by finbarr1987 »

dkarl wrote: post #71
nallana wrote: post #19

Earlier quoted context omitted.

@mNovak -- super helpful note! Thank you! Author of RunMat (this project) here -- > The first thing they teach about performant Matlab code is that simple for-loops will tank performance. Yes! Since in RunMat we're building a computation graph and fusing operations into GPU kernels, we built the foundations to extend this to loop fusion. That should allow RunMat to take loops as written, and unwrap the matrix math in…

Piggybacking on this comment to say, I bet a lot of people's first question will be, why aren't you contributing to Octave instead of starting a new project? After reading this declaration of the RunMat vision, the first thing I did was ctrl-f Octave to make sure I hadn't missed it. Honest question, Octave is an old project that never gained as much traction as Julia or NumPy, so I'm sure it has problems, and I would…

Fair question, and agreed we should make this clearer on the site.

We like Octave a lot, but the reason we started fresh is architectural: RunMat is a new runtime written in Rust with a design centered on aggressive fusion and CPU/GPU execution. That’s not a small feature you bolt onto an older interpreter; it changes the core execution model, dataflow, and how you represent/optimize array programs.

Could you add a JIT to Octave? Maybe in theory, but in practice you’d still be fighting the existing stack and end up with a very long, risky rewrite inside a mature codebase. Starting clean let us move fast (first release in August, Fusion landed last month, ~250 built-ins already) and build toward things that depend on the new engine.

This isn’t a knock on Octave, it’s just a different goal: Octave prioritizes broad compatibility and maturity; we’re prioritizing a modern, high-performance runtime for math workloads.

Re: In Defense of Matlab Code

#102

Post by KingMob »

Ehhh, as someone who did cognitive neuroscience in grad school and wrote non-stop Matlab 20 years ago, this is correct but insufficient. The toolbox and licensing situation sucked, but that's not why I hated it.

At the time, we had massive issues with using Matlab with large fMRI/EEG/MEG data sets, and attempts to write naive matrix-based versions of code would occasionally blow up memory consumption, and turn a 3-week analysis into a 50-year analysis.

So, yeah, I had to replace a decent amount of pretty matrix code into gnarly, but performant, for loops. Maybe the situation has improved since then, but I don't care to find out.

---

Want strings? You had your choice of cells or 2D char matrices? Who ever thought char matrices were a good idea? strfind() vs findstr()? Even after years of Matlab, I had to double-check the docs to recall which one I wanted.

---

Anything to encourage reliability or assist scientists in their workflows, like built-in version control? Nope. Or basic testing support for your ad hoc statistical functions? No.

I guarantee there's a ton of Matlab code that produced biased/wrong results, and nobody knows because it produced numbers in the expected range, and nobody ever thought to check it.

Mathworks was in a unique position to improve scientific code quality, and did nothing with it.

---

Matlab really excelled at only two things: matrix math and making pretty plots. As soon as you needed to do anything else, it was unbelievably painful, and that's where my personal dislike came from.

Re: In Defense of Matlab Code

#103

Post by finbarr1987 »

gmadsen wrote: post #96
lemonwaterlime wrote: post #2

There's also Julia. Earlier in my career, I found that my employers would often not buy Matlab licenses, or would make everyone share even when it was a resource needed daily by everyone. Not having access to the closed-source, proprietary tool hurt my ability to be effective. So I started doing my "whiteboard coding" in Julia and still do.

simulink is the matlab moat ,not just general math expression

Pictorus is a simulink alternative https://www.pictor.us/simulink-alternative

Re: In Defense of Matlab Code

#104

Post by waterTanuki »

Most, if not all the points made in the article, seem to stem from a sense of "we need to optimize the code to be readable by mathemeticians, not programmers" which is fair, depending on what you're doing. But goes a bit overboard with the safety argument, which we've seen much better ROI by focusing on memory safety, rather than abstract mathematical proofs.

In fact, the entire safety argument is undermined by the author themselves:

> The engine is closed source. You cannot see how fft or ode45 are implemented under the hood. For high-stakes engineering, not being able to audit your tools is a risk.

What's the point of optimizing your code to be easy for physicists/mathematicians to read for safety, when you can't even verify what the compiler will produce?

I suppose it basically boils down to whether your orgs engineering is run by academics or software engineers, but Matlab doesn't really do anything that python can't for free. And python is more accessible, has more use cases, and strong academic support already.

Re: In Defense of Matlab Code

#105

Post by quietbritishjim »

themeiguoren wrote: post #40

Of the things matlab has going for it, looking just like the math is pretty far down the list. Numpy is a bit more verbose but still 1-to-1 with the whiteboard. The last big pain point was solved ( https://peps.python.org/pep-0465/ ) with the dedicated matmul operator in python 3.5. Real advantages of matlab: * Simulink * Autocoding straight to embedded * Reproducible & easily versioned environment * Single-source de…

> Big disadvantages of matlab:

I will add to that:

* it does not support true 1d arrays; you have to artificially choose them to be row or column vectors.

Ironically, the snippet in the article shows that MATLAB has forced them into this awkward mindset; as soon as they get a 1d vector they feel the need to artificially make it into a 2d column. (BTW (Y @ X)[:,np.newaxis] would be more idiomatic for that than Y @ X.reshape(3, 1) but I acknowledge it's not exactly compact.)

They cleverly chose column concatenation as the last operation, hardly the most common matrix operation, to make it seem like it's very natural to want to choose row or column vectors. In my experience, writing matrix maths in numpy is much easier thanks to not having to make this arbitrary distinction. "It's this 1D array a row or a column?" is just over less thing to worry about in numpy. And I learned MATLAB first, do I don't think I'm saying that just because it's what I'm used to.

Re: In Defense of Matlab Code

#106

Post by sbrother »

SatvikBeri wrote: post #33
drnick1 wrote: post #15

Earlier quoted context omitted.

I don't think Julia really solves any problems that aren't already solved by Python. Python is sometimes slower (hot loops), but for that you have Numba. And if something is truly performance critical, it should be written or rewritten in C++ anyway. But Julia also introduces new problems, such as JIT warmup (so it's not really suitable for scripting) and is still not considered trustworthy: https://yuri.is/not-julia…

> Python is sometimes slower (hot loops), but for that you have Numba This is a huge understatement. At the hedge fund I work at, I learned Julia by porting a heavily optimized Python pipeline. Hundreds of hours had gone into the Python version – it was essentially entirely glue code over C. In about two weeks of learning Julia, I ported the pipeline and got it 14x faster. This was worth multiple senior FTE salaries.…

> People usually use C++ or Julia. All of the fastest answers are in Julia

That's surprising to me and piques my interest. What sort of pipeline is this that's faster in Julia than C++? Does Julia automatically use something like SIMD or other array magic that C++ doesn't?

Re: In Defense of Matlab Code

#107

Post by D-Machine »

KingMob wrote: post #102

Ehhh, as someone who did cognitive neuroscience in grad school and wrote non-stop Matlab 20 years ago, this is correct but insufficient. The toolbox and licensing situation sucked, but that's not why I hated it. At the time, we had massive issues with using Matlab with large fMRI/EEG/MEG data sets, and attempts to write naive matrix-based versions of code would occasionally blow up memory consumption, and turn a 3-we…

Have to agree, working with fMRI and MRI data. Matlab is nearly impossible to debug or even find basic workarounds for problems in this domain, in comparison to Python, because of how closed and niche Matlab is, and the lack of community and trustworthy documentation, or ability to write sensible code with performant for loops.

In my experience, those arguing for the value of Matlab are mostly 50+ years old, or are in an extremely niche industry using something like e.g. Simulink or other highly-industry-specific tooling, in which case it seems the considerations are irrelevant to something like 99.5% of the modern population.

Matlab will clearly be dead and irrelevant otherwise, in a short amount of time and in almost all domains.

EDIT: And few things indicate an out-of-touch / cookie-cutter or almost-certainly p-hacked neuroscience paper like the use of MATLAB. It is a smell for incompetent legacy research in this domain.

Re: In Defense of Matlab Code

#108

Post by D-Machine »

Defending Matlab code in 2025 is like defending Emacs: it's not that you don't have logically good points, in many cases, it is just that you are so completely out of touch with modern advances, communities, and requirements that it isn't even clear that you are speaking to anything more than what amounts to a rounding error.

EDIT: Specifically, it is extremely hard for me to think that anyone should be convinced to learn Matlab in 2025 - this seems to be a statistically useless and obviously soon-dying skill. Any logical arguments about what Matlab offers NOW seem to entirely ignore - what seems to me - this obvious practical reality.

Re: In Defense of Matlab Code

#109

Post by drnick1 »

SatvikBeri wrote: post #33
drnick1 wrote: post #15

Earlier quoted context omitted.

I don't think Julia really solves any problems that aren't already solved by Python. Python is sometimes slower (hot loops), but for that you have Numba. And if something is truly performance critical, it should be written or rewritten in C++ anyway. But Julia also introduces new problems, such as JIT warmup (so it's not really suitable for scripting) and is still not considered trustworthy: https://yuri.is/not-julia…

> Python is sometimes slower (hot loops), but for that you have Numba This is a huge understatement. At the hedge fund I work at, I learned Julia by porting a heavily optimized Python pipeline. Hundreds of hours had gone into the Python version – it was essentially entirely glue code over C. In about two weeks of learning Julia, I ported the pipeline and got it 14x faster. This was worth multiple senior FTE salaries.…

The C++ devs at your firm must be absolutely terrible if a newcomer using a scripting language can write faster software, or you are not telling the whole story. All of NumPy, Julia, MATLAB, R, and similar domain-specific, user-friendly libraries and platforms use BLAS and LAPACK for numerical calculations under the hood with some overhead depending on the implementation, so a reasonably optimized native implementation should always be faster. By the looks of it the C++ code wasn't compiled with -O3 if it can be trivially beaten by Julia.

Re: In Defense of Matlab Code

#110

Post by quietbritishjim »

BobbyTables2 wrote: post #84
freehorse wrote: post #81

Earlier quoted context omitted.

Why is the `[1,2,3] + [4;5;6]` syntax a footgun? It is a very concise, comprehensible and easy way to create matrices in many cases. Eg if you have a timeseries S, then `S - S'` gives all the distances/differences between all its elements. Or you have 2 string arrays and you want all combinations between the two. The diag is admittedly unfortunate and it has confused me myself, it should actually be 2 different funct…

What does it even mean to add a 1x3 matrix to a 3x1 matrix ?

It means the same thing in MATLAB and numpy:

   Z = np.array([[1,2,3]])
   W = Z + Z.T
   print(W)
Gives:

   [[2 3 4]
    [3 4 5]
    [4 5 6]]
It's called broadcasting [1]. I'm not a fan of MATLAB, but this is an odd criticism.

[1] https://numpy.org/devdocs/user/basics.broadcasting.html#gene...

Post reply on HN