"5000 Erlangs" - oh, they meant 5000 instances of some Erlang interpreter. Not Erlang as a unit of measure.[1] One voice call for one hour is one Erlang. [1] https://en.wikipedia.org/wiki/Erlang_(unit)
What does 5000 Animats measure? Does 1 Animat convert to metric nitpicks? You know you're successful once you're added to: https://www.theregister.com/Design/page/reg-standards-conver...
Booting 5000 Erlangs on Ampere One 192-core
41–50 of 51 posts
Re: Booting 5000 Erlangs on Ampere One 192-core
#42Earlier quoted context omitted.
> Erlang, at least the programming model, lends itself well to this, where each process has a local heap. If that can stay resident to a subsection of the CPU, that might lend itself better to a reasonably priced many core architecture. I tend to agree. Where it gets -really- interesting to think about, are concepts like 'core parking' actors of a given type on specific cores; e.x. 'somebusinessprocess' actor code al…
The BEAM launches a scheduler process per CPU thread in SMP mode, although I don't know if it moves Erlang processes between them.
The behavior is configurable and the default is unbound.
Re: Booting 5000 Erlangs on Ampere One 192-core
#43Earlier quoted context omitted.
Paraphrasing the late great Joe Armstrong, the great thing about Erlang as opposed to just about any other language is that every year the same program gets twice as fast as last year. Manycores hasn't succeeded because frankly the programming model of essentially every other language is stuck in 1950. I, the program, am the entire and sole thing running on this computer, and must manually manage resources to match i…
I'm curious, which actor model warts are you referring to exactly? [The obvious candidates from my point of view are (1) it's an abstract mathematical model with dispersed application/implementations, most of which introduce additional constraints (in other words, there is no central theory of the actor model implementation space), and (2) the message transport semantics are fixed: the model assumes eventual out-of-o…
I don't think either of those are particularly problematic. The actor model as implemented by Erlang is concrete and robust enough. The big problems with the actor model are, in my opinion, around (1) speed optimizations for immutable memory and message passing (currently, there's a great deal of copying and pointer chasing involved, which can be slow and is a ripe area for optimization), (2) (for Erlang) speed and QOL improvements for math and strings (Erlang historically is not about fast math or string handling, but both of those do comprise a great deal of general purpose programming), (3) (for Erlang) operational QOL misc improvements (e.g. existing distribution, ets, amnesia, failover, hot upgrade, node deployment, build process range from arcane (amnesia, hot upgrades, etc.all the way up to covered-in-terrifying-spiders (e.g. debugging queuing issues, rebar3))
Re: Booting 5000 Erlangs on Ampere One 192-core
#44I would be much more interesting in seeing 5000 under heavy load. Just being able to star that many instances is not that exciting until we know what they can do.
Erlang handles heavy load VERY well, between work stealing schedulers and soft realtime via reduction counting (any program can be interrupted and stopped after any instruction and resumed transparently)
That is good.
Then actual propper benchmarks will be remarkable.
However BEAM is not the only factor in this process. the entire hardware platform as well.
This is after all a lot about that nice and huge cpu.
I mean when you have all 5000 started why not let the do some work? Stress test it with a few real life scenarios for 48h and let us see some number.
Re: Booting 5000 Erlangs on Ampere One 192-core
#45Earlier quoted context omitted.
I'm curious, which actor model warts are you referring to exactly? [The obvious candidates from my point of view are (1) it's an abstract mathematical model with dispersed application/implementations, most of which introduce additional constraints (in other words, there is no central theory of the actor model implementation space), and (2) the message transport semantics are fixed: the model assumes eventual out-of-o…
I don't think either of those are particularly problematic. The actor model as implemented by Erlang is concrete and robust enough. The big problems with the actor model are, in my opinion, around (1) speed optimizations for immutable memory and message passing (currently, there's a great deal of copying and pointer chasing involved, which can be slow and is a ripe area for optimization), (2) (for Erlang) speed and Q…
There is no lineage between The Actor Model and Erlang. The creators of Erlang are on record as having never heard of the Actor Model (as developed by Hewitt, Agha and colleagues at MIT). None of the points you make (including the first one) are a part of any formal definition or elaboration of the Actor Model that I have seen, which was one of my points: there is no unified theory of the Actor Model that addresses all of the practical issues.
With respect to your point (1), you might be interested in Pony, which has been discussed here from time to time, most recently: https://news.ycombinator.com/item?id=44719413 Of course there are other actor-based systems in wide use such as Akka.
Re: Booting 5000 Erlangs on Ampere One 192-core
#46"5000 Erlangs" - oh, they meant 5000 instances of some Erlang interpreter. Not Erlang as a unit of measure.[1] One voice call for one hour is one Erlang. [1] https://en.wikipedia.org/wiki/Erlang_(unit)
Neat! I always thought the name of the Erlang programming language just meant “Ericsson Language”, since this programming language was invented for Ericsson. Never knew there was anything more than that to the name!
According to Robert Virding at an unnamed bar in Berlin ~3 years ago they just wanted to be like Pascal in terms of picking a mathematician. But Ericsson Language certainly helped sell it internally, I'm sure.
Re: Booting 5000 Erlangs on Ampere One 192-core
#47"5000 Erlangs" - oh, they meant 5000 instances of some Erlang interpreter. Not Erlang as a unit of measure.[1] One voice call for one hour is one Erlang. [1] https://en.wikipedia.org/wiki/Erlang_(unit)
I was aware an Erlang being a unit though I'd forgotten what it measured. I Need to have my fun when giving titles to these things. Hope it fell within bearable tolerances.
Re: Booting 5000 Erlangs on Ampere One 192-core
#48So this is something like a 5000 USD machine ( https://www.jeffgeerling.com/blog/2024/ampereone-cores-are-n... ) And is designed as a cloud provider or telco edge machine (hence the erlang consultancy) But if you are looking at a hosted erlang VM for a capex of one dollar then these folks are onto something Cores really are the only way to escape the broken moores law - and this does look like a real step in the impo…
I found out that Ampere is into edge and telco usage way after we got connected to do this work actually. I've been an Elixir dev and through that connected to Erlang for 7-ish years.
But I will certainly try to leverage my telco-connection to get to play with more of their kit if I can.
Re: Booting 5000 Erlangs on Ampere One 192-core
#49So this is something like a 5000 USD machine ( https://www.jeffgeerling.com/blog/2024/ampereone-cores-are-n... ) And is designed as a cloud provider or telco edge machine (hence the erlang consultancy) But if you are looking at a hosted erlang VM for a capex of one dollar then these folks are onto something Cores really are the only way to escape the broken moores law - and this does look like a real step in the impo…
The article is about 5000 Erlang nodes (BEAM VMs), not processes - a single BEAM instance can efficiently handle millions of lightweight processes, making this even more impressive from a density perspective.
I really should see how many 1 million process BEAM VMs can fit...
Re: Booting 5000 Erlangs on Ampere One 192-core
#50“ Underjord is an artisanal consultancy …” If they don’t weave Erlang threads by hand I’m going to be mildly disappointed.
The advice in every consultation is either mouth-spoken or finger-written by a 100% organic (but not currently certified) entity.