Thanks!! It was originally for Octave users whose scripts were running painfully slow.

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).