nallana

Also on the team here. Feel free to ask any questions — we’ll be monitoring this thread for the next few hrs!

Curious what other’s views on DSLs are post-LLMs too

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!

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?