[nallana]

@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 the computation graph into singular GPU programs -- effectively letting loop written math run super fast too.

Will share more on this soon as we finish loop fusion, but see `docs/fusion/INTERNAL_NOTE_FLOOPS_VM_OPS.md` in the repo if curious (we're also creating VM ops for math idioms where they're advantageous).

> Would love to see something with the convenient math syntax of Matlab, but with broader ease of use of something like JS.

What does "convenient math syntax of Matlab, but with broader ease of use of something like JS" look like to you? What do you wish you could do with Matlab but can't / it doesn't do well with?

[dkarl]

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 wouldn't be surprised if you have excellent reasons for starting fresh. I'm just curious to hear what they are, and I suspect you'll save yourself some time fielding the same question over and over if you add a few sentences about it. I did find [1] on the site, and read it, but I'm still not clear on if you considered e.g. adding a JIT to Octave.

[1] https://runmat.org/blog/matlab-alternatives

[finbarr1987]

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.

[zackmorris]

Piggybacking also to say that I hope you succeed, as your work aligns closely with the type of runtime that I had hoped to write someday when I first used MATLAB in the early 2000s (now mostly GNU Octave for small hobby projects).

The loop fusion idea sounds amazing. Another point of friction which I ran into is that MATLAB uses 1-based offsets instead of 0-based offsets for matrices/arrays, which can make porting code examples from other languages tricky. I wish there was a way to specify the offset base with something like a C #define or compiler directive. Or a way to rewrite code in-place to use the other base, a bit like running Go's gofmt to format code. Apologies if something like this exists and I'm just too out of the loop.

I'd like to point out one last thing, which is that working at the fringe outside of corporate sponsorship causes good ideas to take 10 or 20 years to mature. We all suffer poor tooling because the people that win the internet lottery pull up the ladder behind them.

[markkitti]

> I wish there was a way to specify the offset base with something like a C #define or compiler directive.

Julia has OffsetArrays.jl implementing arbitrary-base indexing: https://juliaarrays.github.io/OffsetArrays.jl/stable/

The experience with this has been quite mixed, creating a new surface for bugs to appear. Used well, it can be very convenient for the reasons you state.

  julia> A = collect(1:5)
  5-element Vector{Int64}:
   1
   2
   3
   4
   5

  julia> B = OffsetArray(A, -1)
  5-element OffsetArray(::Vector{Int64}, 0:4) with eltype Int64 with indices 0:4:
   1
   2
   3
   4
   5

  julia> A[1]
  1

  julia> B[0]
  1

[Alexander-Barth]

I wish you all the best luck with your product!

Unfortunately, mathworks is a quite litigious company. I guess you are aware of mathworks versus AccelerEyes (now makers of ArrayFire) or Comsol.

For our department, we mostly stop to use MATLAB about 7 years ago, migrating to python, R or Julia. Julia fits the "executable math" quite well for me.

[fluidcruft]

All anyone really needs is seamless integration of Julia with python. Instead everyone seems to be rewriting python into rust.

[FacelessJim]

Checkout PythonCall.jl and juliacall (on the python side). Not to mention that now you can literally write python wrappers of Julia compiled libraries like you would c++ ones.

[fluidcruft]

I will, thanks.

> you can literally write python wrappers of Julia compiled libraries like you would c++ ones

Yes, please. What do I google? Why can't julia compile down to a module easily?

No offense but once you learn to mentally translate between whiteboard math and numpy... it's really not that hard. And if you were used to Matlab before Mathworks added a jit you were doing the same translation to vectored operations because loops are dog slow in Matlab (coincidentally Octave is so much better than Matlab syntax wise).

And again python has numba and maybe mojo, etc. Because julia refused to fill the gap. I don't understand why there's so much friction between julia and python. You should be able to trivially throw a numpy array at julia and get a result back. I don't think the python side of this is holding things back. At least back in the day there was a very anti-python vibe from julia and the insistence that all the things should be re-implemented in julia (webservers etc) because julia was out to prove it was more than a numerical language. I don't know if that's changed but I doubt it. Holy wars don't build communities well.

[markkitti]

>> you can literally write python wrappers of Julia compiled libraries like you would c++ ones. > Yes, please. What do I google? Why can't julia compile down to a module easily?

Try JuliaC for compiling shared libraries if that is what you mean by a "module": https://github.com/JuliaLang/JuliaC.jl

That said Julia's original design focused on just-in-time compilation rather than ahead-of-time compilation, so the AOT process is still rough.

> I don't understand why there's so much friction between julia and python. You should be able to trivially throw a numpy array at julia and get a result back.

You can throw a numpy array at Julia and get a result back. See https://juliapy.github.io/PythonCall.jl/stable/juliacall/