You have awakened my curiosity regarding Elixir. I read up on OTP and the Beam VM and find this new world (for me) very fascinating. Never knew that the Swedish company Ericsson created the OTP (Open Telecom Platform) that was built on Erlang VM/ BEAM. The entire paradigm is new to me but very convincing in its features. Thanks. I am watching Jose Valim’s talk now.
I am very impressed with Elixir and how it handles: Concurrency, Fault Tolerance and Supervision with responsiveness as well as hot fixes. Python can only approach this with a no-GIL version and is still very heavy and complex to implement by any comparison. I am definately going to invest some time learning theElixir language and BEAM/OTP frameworks.
1 Like
There are various folks who make good videos about Elixir. One of my favorites is Dave Thomas, a prolific author, speaker, and publisher on topics such as Ruby and Elixir. Here are links to some of his talks…
I’d also strongly recommend watching some of Joe Armstrong’s talks. Joe was the lead designer for Erlang and his design decisions created the solid foundation for José’s work. Try:
This is (IMHO) a wonderful introduction to the thinking behind Erlang (and so, to a great degree, Elixir). If you’ve been spending all of your time thinking about how to make a Python module emulate a cortical column, this talk will give you lots of ideas about how zillions of modules could (and really, must) work together to build real Monty systems.
This talk, from a seminar at Stanford, is a bit of a historical rundown of Erlang’s development. However, it uses work done for the Tandem Computers fault tolerant hardware design as a theoretical starting point and basis for comparisons.
This talk is also fun, but less tied to Erlang et al. It’s basically the ramblings of a (very smart) geezer…
This talk is mostly a high-level tour of Erlang’s Supervision Trees, giving their rationale, design approach, etc.
1 Like
Thanks for all the links to great references. I am ingesting them all and love the content.
I was curious about performance comparisons between BEAM (Erlang concurrency) and CUDA parallelism on GPUs. I and now convinced that BEAM performs much better (and on top, fault tolerant) than CUDA for processes that need frequent inter-process) communication.
I found the following facts:
Interdependent Parallel Tasks: BEAM vs CUDA
When parallel tasks are interdependent, especially with frequent communication (e.g., every 2ms), the architecture and scheduling model become critical. Here’s how BEAM and CUDA compare in this scenario:
Why BEAM Excels in This Case
-
Lightweight Processes: BEAM can handle millions of lightweight processes with fast context switching.
-
Message Passing: Erlang’s concurrency model is built around asynchronous message passing, which is ideal for interdependent tasks.
-
Low Latency Scheduling: BEAM uses a preemptive scheduler with soft real-time guarantees, ensuring tasks are responsive even under load.
-
No Shared Memory: This avoids locking and contention issues common in shared-memory models.
So, if tasks need to communicate or synchronize every few milliseconds, BEAM is much better suited than CUDA.
Why CUDA Struggles Here
-
Designed for Data Parallelism: CUDA excels at tasks where threads operate independently on large datasets.
-
Synchronization Overhead: Frequent inter-thread communication or synchronization (like every 2ms) introduces significant overhead.
-
Latency Sensitivity: CUDA is not optimized for low-latency interdependent operations—it’s built for throughput, not responsiveness.
Conclusion
If your parallel tasks depend on each other and communicate frequently, BEAM is the better choice. CUDA is ideal when tasks are independent and compute-heavy, but not when they need to coordinate often.
I envision the CMP running on BEAM across columns, all in break-neck speed. Elixir is my new interest.
You’re probably well aware of Axon, EXLA, Nx, etc. But just in case, here are some links…
Introducing Nx - José Valim | Lambda Days 2021
On a vaguely related note, it’s worth mentioning that a lot of Elixir (including the main compiler and Nx support) are implemented as (Lisp-style, hygienic) macros. This allows all sorts of cool magic under the hood, as well as letting Elixir developers extend the language as needed. Pretty cool…
This is very exciting, to discover this very delicious ecosystem with so many unique flavors. And it feels like it connects the magic of the Minsky days with todays Hawking’s magic. I never expected to find this bridge. Thanks again!
I just ran across a really cool video, for anyone interested in Actors, concurrency, etc.
When considering the panel to discuss concurrency, you’d be pushed to find a higher calibre than Sir Tony Hoare, Joe Armstrong, and Carl Hewitt. All greats within the industry and beyond, they give an amazing insight into the lifeline of concurrency and actor models over the past few decades, their bountiful experiences within the concurrency field, and where they see concurrency heading in the future.
Let’s #TalkConcurrency -
panel discussion, moderated by Francesco Cesarini, with:
Concurrency-related structural conventions of Go (channels and alternative channel inputs) are derived from Tony Hoare’s communicating sequential processes model.