Erlang/Elixir and supercomputers

These supercomputers are working on parallelizable problems, yes, but need raw speed such as for modeling climate change. They might even use specialized languages for the computations. A BEAM language may be good for supervising the process farm but other than that there needs to be mutable data structures and fast matrix computations.

At my university there is a supercomputer. My Erlang lecturer told us once, that BEAM was the only technology to make use of all of its cores. But I don’t think there were some advanced computations included, it was rather a show off of concurrency. BEAM may not be best for scientific computations on these machines, but I heard that my peers are going to launch highly distributed version of Conway’s game of life on one of them, using Erlang of course. This should turn out really cool

I really do wonder what would happen if we had a pure dependently typed actor-model functional language. This would enable us to use crazy tricks like process-based memoization, and have the compiler do all kind of weird things for us to make programs faster.

It is completely possible to use mutable data structures in a purely functional language by using a State Monad Transformer (But I have to admit, this is the kind of stuff that Mathematics Professors discuss about with squiggely lines and vague terms – I don’t understand how this works myself either right now).

I think the domain of BEAM and these supercomputers is different. These kind of computer want a lot of parallelization and probably will use specially made languages or very specialized languages like Futhark or CUDA.

I started out my career working at the San Diego Supercomputer Center on some of the very early multiprocessor supercomputers of the day (i.e. when a 1000 cores was a supercomputer). My interest in concurrency started there and eventually lead me to Erlang and Elixir.

While there are some simulations that could effectively use the BEAM, most supercomputer type problems don’t translate well to the actor model due to the connectivity of the data. For large physical simulations, every data point affects the value of every other data point in the simulation.

The Actor model assumes a network of minimal connections. If every process needs to talk to every other process then communication dominates costs as you scale the problem.

Now on the other hand, almost all of the science of numerical computation is figuring out when it’s “okay” to ignore the connections between data in a problem and partition the problem into smaller solvable problems.

I think the BEAM could work in these environments as scheduler and coordinator, but you’d need a specialized core of mathematical routines that currently doesn’t exist.

This question was raised in June 2016. Would the answers to this question today (October 2023) be different than they were back then?