nallana

They haven’t been all this time? Damn — what a time to be a robot

Why not a shared buffer? Serializing into JSON on this hot path should be entirely avoidable

Appreciate the comment actually! It's good feedback -- we weren't sure if it's mixing work/memes too much, and keeping our materials clean like engineering docs are probably a good way to go. We may edit it out of the post.

Cheers for the comment!

It's open source / free. But yes, of course we want people to try it and get value from it.

Seeing in MATLAB code how ode45 is implemented != how the thing is running on the machine. That's a very small top slice.

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

Shameless plug for RunMat (we wrote this blog article, also an open source alternative for MATLAB):

https://runmat.org

Yep -- Octave was very helpful for me in school.

Octave is not particularly fast.

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

> 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. This is just a lie. Open matlab and you can inspect all the implementation details behind ode45. It is not a black box.

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.

If the rewrite is for performance, ideally the logic capture = the thing executing in production.

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

Yep! Makes sense. Though I think the cost of writing these toolboxes is lim --> 0.

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

In Julia, you explicitly need to still reason about and select GPU drivers + manage residency of tensors; in RunMat we abstract that away, and just do it for you. You just write math, and we do an equivalent of a JIT to just figure out when to run it on GPU for you.

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.

@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?

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

a solid core, not the whole Matlab (they confound the language, compiler / runtime, an IDE, and a bunch of other things in the name / product that is MATLAB).

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

Versus Octave:

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

Hi HN!

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!