Kevin Smith - Erlang & CUDA: Concurrent and Fast (2011)

slides

Machine Learning in Erlang and CUDA

As already alluded to - the BEAM is used for orchestration of computation - because that is what it is good at.

Aside: Simon Marlow: Parallel and Concurrent Programming in Haskell (amazon.com; GPU Programming with Accelerate)

GPUs are completely different animals from CPUs (GPU processors are very small, very limited in what kind of instructions they can execute, but therefore very fast and plentiful.)

Because they are so different, I do not think that a BEAM scheduler would be able to run on there.

If you’d like to make use of the GPU in your code, you might want to look into writing a NIF (such as using rustler and writing it in Rust).

There was research done in the EU with integrating Erlang and CUDA. Just don’t know the details.

Gpu cores are simd. One way to think of it is that you must dispatch the same instruction to all of the cores simultaneously (this is not exactly correct for most modern gpus, but it gives you the flavor of the problem). I do think that the idea of having a process manage a gpu is correct, though, and every other programming language that does gpu stuff does this abstraction wrong. I tried to convince the Julia folks that they should treat the gpu as a virtual “distributed node” that you can dispatch Julia code to (you can do this with distributed cpu nodes on Julia), but they did not pick that idea up.

There is also the Scene library that was presented at ElixirConf.

On the surface it would seem unrelated as it is dedicated to drawing graphics - but it draws those graphics through OpenGL. There is a small step between scheduling graphics on the GPU and scheduling programs to run on the GPU. Scene may or may not have the primitives needed to take that step, but it certainly shows that communicating with the GPU is possible.