[erlang-questions] trouble with erlang or erlang is a ghetto

[Jon Watte]

>
>
> BEAM is starting to make use of NUMA, for example when allowing you to
> control the binding of schedulers to cores. See e.g.
>
>
The real efficiencies come from processes (and their working set) being
bound to particular spots in the memory hierarchy, though.
I imagine that, because processes have affinity for schedulers, then
schedulers being bound to cores would help some, but when the runtime
decides to migrate a process, it probably needs to consider how far down the
memory hierarchy to "fork" the process. (These days, we have to worry about
L1, L2, L3 and NUMA nodes as distinct points in this choice)
Similarly, if one queue is falling behind, and another queue on the same
core (using hyper-threading) is lightly loaded, it doesn't really make sense
to shift load between those two hyper-threads as they are limited on the
same functional units and L1.
It sounds like you're already considering these things; just making sure
it's stated explicitly in this thread!


>
>
> Yes, but one thing I learned while at Ericsson was that NEBS-compliant ATCA
> processor boards don't exactly stay on the leading edge of processor
> capacity.
>

That is of course a consideration. On the other hand, I imagine projects run
over several years, and what's best price/performance in data centers today
will likely trickle down to the telecom industry eventually :-)



>
>
The key, in my experience, is not usually to go as fast as possible, but to
> deliver reliable and predictable performance that is good enough for the
> problem at hand. As many have pointed out through the years, Erlang was
> never about delivering maximum performance.
>
>
>

I'm with you there! If I know that I can add another node to get close to
linear X% increased capacity, that's really powerful.

Sincerely,

jw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110730/cf72ebfc/attachment.htm>