Cheers for the comment!

But okay -- as I mentioned, you're entitled to your views!

https://runmat.org

Octave is not particularly fast.

RunMat is very fast (orders of magnitude -- see benchmarks).

How do I see the .c files / trace how `ode45` will execute on my machine? Can I see the JIT's source code?

--

Entitled to your view, but clearly difference of opinion here. From perspective of open / closed source -- maybe for you it qualifies as open source, but I can't follow the logic chain, so to me MATLAB is not open source.

Cases where a JIT running would conflict with requirements notwithstanding (e.g. HIL with strict requirements and whatnot)...

Will have a really solid rust inspired package manager soon, and a single #macro to expose a rust function in the RunMat script's namespace (= easy to bring any aspects of the rust ecosystem to RunMat).

Our goal is to make a runtime that lets people stay at the math layer as much as possible, and run the math as fast as possible.

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?

The goal was to keep the MATLAB frontend capture syntax, but run it fast.

When we dug into why people were still using Octave, it was because it let them focus on their math, and was easier for them to read - was especially important for people that aren’t programmers; eg scientists and engineers.

I suppose this is also why we write in higher level languages than assembly.

The goal of this project is now: let’s make the fastest runtime in the world to run math.

Turned out, the MATLAB syntax offers a large amount of compiler time hinting in (it is meant for math intent capture after all).

We’ve found as we built this that if we take a domain specific approach (eg we’re going to make every optimization for what’s best for people wanting to focus on the math part), we can outperform general purpose languages like Python by a large mile on the math part.

For example, internals like keeping tensor shapes + broadcasting intent within the AST, and having the computation graph available for profitable GPU/CPU threshold detection isn’t something that makes practical sense to build into a general purpose runtime like Python, but —

It lets RunMat speed up elementwise math orders of magnitude (eg 1B points going through 5-6 element wise ops like sin/cos/+/- etc are 80x faster on my MBP vs Python/PyTorch).

So Tl;dr — started as for Octave users. Goal is to build the fastest runtime for math for those that are looking to use computers to do math.

Obligatory disclosure because we’re engineers: you can still get faster by writing your own CUDA / GPU code. We’re betting 99% of the people that are trying to run math using computers don’t want to do that (ML community notwithstanding).

Since then, I’ve taken it further with RunMat Accelerate: the runtime now automatically fuses operations and routes work between CPU and GPU. You write MATLAB-style code, and RunMat runs your computation across CPUs and GPUs for speed. No CUDA, no kernel code.

Under the hood, it builds a graph of your array math, fuses long chains into a few kernels, keeps data on the GPU when that helps, and falls back to CPU JIT / BLAS for small cases.

On an Apple M2 Max (32 GB), here are some current benchmarks (median of several runs):

* 5M-path Monte Carlo * RunMat ≈ 0.61 s * PyTorch ≈ 1.70 s * NumPy ≈ 79.9 s → ~2.8× faster than PyTorch and ~130× faster than NumPy on this test.

* 64 × 4K image preprocessing pipeline (mean/std, normalize, gain/bias, gamma, MSE) * RunMat ≈ 0.68 s * PyTorch ≈ 1.20 s * NumPy ≈ 7.0 s → ~1.8× faster than PyTorch and ~10× faster than NumPy.

* 1B-point elementwise chain (sin / exp / cos / tanh mix) * RunMat ≈ 0.14 s * PyTorch ≈ 20.8 s * NumPy ≈ 11.9 s → ~140× faster than PyTorch and ~80× faster than NumPy.

If you want more detail on how the fusion and CPU/GPU routing work, I wrote up a longer post here: https://runmat.org/blog/runmat-accel-intro-blog

You can run the same benchmarks yourself from the GitHub repo in the main HN link. Feedback, bug reports, and “here’s where it breaks or is slow” examples are very welcome.

Comments URL: https://news.ycombinator.com/item?id=46121951

Points: 21

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=45224625

Points: 7

# Comments: 4

This is a solid compiler + minimal runtime, with an architecture designed to scale.

- Lots of language semantics are unsupported in Octave (like Classes), and it’s purely a slow line by line interpreter so it’s very slow.

- Given the design / Cranelift IR translation here, RunMat can run natively on any compile target for which Cranelift [currently x86-64, aarch64 (ARM64), s390x (IBM Z), and riscv64], and targeting additional ISAs is easy. The net of this: you can write controls / logic in Matlab code and run it natively on device.

- GPU acceleration; the foundations are in place so RunMat can natively accelerate Tensor / Matrix math on GPUs, irrespective of device (eg CUDA / Metal / Vulcan / etc). Net of this is that you can do much bigger math calculations even faster (and without having to worry about moving things on/off GPU memory; there’s a configurable (and substitutable) planner built in that does scatter / gather intelligently for you). The AST is extensively typed, and we can support things like reverse-grade autograd by default -> your math runs even faster than would natively in Octave or even Matlab (I believe Matlab has a separate toolbox where you can do some of this, but it’s not natively how their matrix math works / they try and upsell for that).

- Once the package manager is complete, you can extend it. Octave doesn’t really have a package system per se.

GNU Octave has been the main open-source way to run MATLAB code but it only supports a subset of the grammar and semantics, and its performance is far behind modern expectations. It’s more of a compatibility bridge than a true runtime alternative.

I decided to implement a MATLAB language compiler and executor from scratch, grammar and semantics complete, in Rust with a modern architecture inspired by V8. Like V8, RunMat starts in a lightweight interpreter, then profiles and JITs hot paths using Cranelift. Snapshotting makes cold start essentially vanish (5ms vs 2–10s in MATLAB), and tensor operations run natively across CPUs or GPUs (CUDA, Metal, Vulkan) without an extra license.

Performance (vs Octave, Apple M2 Max, 32GB): * Startup: 0.9147s → 0.005s (180× faster) * Matrix ops: 0.8220s → 0.005s (164×) * Math funcs: 0.8677s → 0.0053s (160×) * Control flow: 0.8757s → 0.0057s (154×)

Unlike Octave, RunMat implements the full MATLAB grammar: arrays/indexing (end/colon/masks/N-D), multiple returns, varargin/varargout, classdef OOP, events/handles, metaclass, and standardized exceptions. The core is slim at 5MB static binaries for Linux, macOS, and Windows (or embedded devices and containers), with language extensibility coming from packages that can be written in MATLAB or in Rust.

It’s 100% open source: The repo is about 3M characters of code, has over 1,000 tests covering the edges of the semantic surface, and was bootstrapped in three weeks. A package manager is next, along with a final draft of the builtin standard library.

TLDR: Same language semantics, but rebuilt with modern methods, the way Chrome’s V8 redefined JavaScript engines.

Comments URL: https://news.ycombinator.com/item?id=44972919

Points: 15

# Comments: 6

Would love to share something that has been over a year in the making.

We were originally building an environment to conduct engineering / scientific analysis in the cloud (lambda compute w/ visual outputs for figures and what not).

Design intent was to enable mechanical / electrical engineering teams with basic programming skills (2-3 courses) to harness SW better. I came from a SW background before working in HWE at Apple for a number of years, and saw just how many things people were doing that could be automated if non-SWEs just knew how to set up a CRON or trigger based job (or even install Python!).

We experimented with adding Codex to the product, and the result has turned out to be pretty remarkable.

Since we launched on LinkedIn 2w ago, we’ve been adding new users like crazy.

People are using the product like a graphing calculator on steroids. Like if Matlab meets the team collaborative aspect of Figma. Others are ditching their TI-84s and Excel spreadsheets which they were using for multi-step math to Dystr instead.

Would absolutely love feedback! Please do forward either here, or emailing us (team@ root domain).

Also! Desktop only for now; will release mobile compatibility when development resources allow!

Comments URL: https://news.ycombinator.com/item?id=34570797

Points: 17

# Comments: 1