Live data from Hacker News

Booting 5000 Erlangs on Ampere One 192-core

underjord.io

11–20 of 51 posts

Re: Booting 5000 Erlangs on Ampere One 192-core

#12

So 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…

While not this exact server, from Hetzner, you can get an 80-core Ampere for just ~$200 per month.

(And that also includes hosting, egress, power, etc).

https://www.hetzner.com/dedicated-rootserver/rx170/

Re: Booting 5000 Erlangs on Ampere One 192-core

#13
post #6

So 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 really like the manycores approach, but we haven’t seen it come to fruition — at least not on general purpose machines. I think a machine that exposes each subset of cores as a NUMA node and doesn’t try to flatten memory across the entire set of cores might be a much more workable approach. Otherwise the interconnect becomes the scaling limit quickly (all cores being able to access all memory at speed). Erlang, at…

> think a machine that exposes each subset of cores as a NUMA node and doesn’t try to flatten memory across the entire set of cores might be a much more workable approach. Otherwise the interconnect becomes the scaling limit quickly (all cores being able to access all memory at speed).

Epyc has a mode where it does 4 numa nodes per socket, IIRC. It seems like that should be good if your software is NUMA aware or NUMA friendly.

But most of the desktop class hardware has all the cores sharing a single memory controller anyway, so if you had separate NUMA nodes, it wouldn't reflect reality.

Reducing cross core communication (NUMA or not) is the key to getting high performance parallelism. Erlang helps because any cross process communication is explicit, so there's no hidden communication as can sometimes happen in languages with shared memory between threads. (Yes, ets is shared, but it's also explicit communication in my book)

Re: Booting 5000 Erlangs on Ampere One 192-core

#14
post #6

So 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 really like the manycores approach, but we haven’t seen it come to fruition — at least not on general purpose machines. I think a machine that exposes each subset of cores as a NUMA node and doesn’t try to flatten memory across the entire set of cores might be a much more workable approach. Otherwise the interconnect becomes the scaling limit quickly (all cores being able to access all memory at speed). Erlang, at…

Who knows what will really happen, but there have been rumours of significant core-count bumps in Ryzen 6, which would edge the mainstream significantly closer to manycore.

Re: Booting 5000 Erlangs on Ampere One 192-core

#16

So 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.

Re: Booting 5000 Erlangs on Ampere One 192-core

#19
post #12

So 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…

While not this exact server, from Hetzner, you can get an 80-core Ampere for just ~$200 per month. (And that also includes hosting, egress, power, etc). https://www.hetzner.com/dedicated-rootserver/rx170/

> Product currently not available

in practice you can't though

Re: Booting 5000 Erlangs on Ampere One 192-core

#20
post #6

So 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 really like the manycores approach, but we haven’t seen it come to fruition — at least not on general purpose machines. I think a machine that exposes each subset of cores as a NUMA node and doesn’t try to flatten memory across the entire set of cores might be a much more workable approach. Otherwise the interconnect becomes the scaling limit quickly (all cores being able to access all memory at speed). Erlang, at…

> 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 all happens on a specific fixed set of cores and 'account' actors run on a different fixed set of cores, versus having all the cores going back and forth between both.

Could theoretically get a benefit due to instruction cache being very consistent per core, giving benefits due to the mechanical sympathy (I think Disruptors also take advantage of this).

On the other hand, it may not be as big a benefit, in the sense that cross process writes are cross core writes and those tend to lead to their own issues...

fun to think about.

Post reply on HN