User-friendly language for programming efficient simulations | Hacker News Reader

User-friendly language for programming efficient simulations

news.mit.edu

88 pointsmuhic17 comments

Open articleView on HN

It is worth noting that Simit shares an author with Halide: http://halide-lang.org/

I'd say Halide was definitely a success of domain specific high performance language, so hopefully Simit is too.

It actually shares two authors (Jon and Saman). Their work on Halide was amazing!

Could you please explain what's so special about Halide?

Much more info on their site/github: http://simit-lang.org/language

Also, the paper is available here: http://simit-lang.org/tog16

Also coming out this year with the same goal is Ebb from Stanford: http://ebblang.org

Both languages look cool, but seem fairly limited at the moment -- they are basically DSLs for assembling and solving PSD systems.

What does PSD stand for?

Positive semi-definite, I believe.

Server housing publication PDF's appears to have problems, at the moment.

Archived copies:

http://wayback.archive.org/web/20160828234821/http://groups....

http://wayback.archive.org/web/20160828234958/http://groups....

A presentation of this work is available at: https://www.youtube.com/watch?v=raPkxhHy5ro

It seems like it would be much more straightforward to write a graph-based FEM library for MATLAB than to make an entirely new language around a feature with a very specific and very narrow use case. Still, the high performance aspects of simit seem interesting, assuming that they weren't too badly cherrypicked.

We needed new language constructs (the matrix assembly) and a new type system for matrices that ties back to the graph to make it simple and fast. It is also not limited to FEM codes. It can be used to write any application that computes on sparse systems using linear algebra. Some application areas are optimization, machine learning, data analytics, fluid dynamics, image processing, and robotics.

For more information about the language, why it is designed the way it is, why it is fast, and what applications it can be used for, see the talk I gave at Microsoft Research last Friday: https://youtu.be/raPkxhHy5ro?t=40m32s

This is really cool! You have coded up some timesteppers in Simit already; any plans to release them as a standard package which would be officially optimized, or do you mostly expect users to just roll their own as needed?

Thanks! Yes, we have an `apps` directory in the source tree that we will add programs to. These programs are tested by our test suites, and will later be our performance regressions.

I'm actually working with some people at Adobe this summer to add Local-Global Solvers for ARAP energies (an optimization code) to the set of applications we provide there. We also have an implementation of PageRank.

I really like the idea of a graph-based solver since it makes a lot more sense for matrix assembly, but I'm concerned about committing to using simit because that necessarily implies abandoning interoperability with other established software. I do a lot of evolutionary structural optimization, but I need to also be able to interface with existing software libraries in order to complete the job. I'm not sure how feasible of a port it would be, but myself and many others would be very appreciative of a simit library for an established language. Surely those custom types could be emulated with the object systems found in modern languages?

Very valid concerns. If you use C++ it's easy to interoperate with Simit, since Simit is a C++ library with an online compiler that compile the time steppers. You build the graph using a C++ api and then you run a Simit program which updates the graph. It's similar to how you'd use OpenGL or DirectX (graphs instead of meshes and Simit programs instead of shaders). See https://youtu.be/raPkxhHy5ro?t=19m32s, and http://simit-lang.org/api for more information.

You're absolutely right that we could have provided all the functionality as C++ classes instead of compiling Simit programs through the Simit C++ API, and we might at some point. The reason why we didn't do this is that the language is complex enough that we felt it would be less user friendly. I definitely tried to design it as a library without a parser.

Yea, I'm not really sure what a new language buys them here. It seems they could have just released a library (not even tied to Matlab) with their highly tuned stiffness matrix assembly routines and their kernels...

If you only want the existing kernels, this makes sense. And in the long term it would be useful to have a library of common kernels for assembling FEM stiffness and mass matrices for various kinds of commonly-used elements, etc.

Compare to GSLS; the shading language is unnecessary if you only want to use a handful of pre-made shaders, but usually that is not case.

Reply on news.ycombinator.com