So - I figured out why they’re called “reductions”. It’s a shorthand for “goal-reductions” (I mean, they’re even shortened to “reds” now …), which is a leftover from when Erlang was written in Prolog. A goal-reduction in prolog is essentially a constituent operation of a larger program. This does literally mean that the processes have a set number of operations they’re allowed to run --- the BEAM VM, though, as we saw last night, is now using this as an abstraction to help support operational spikes.
http://erlang.org/pipermail/erlang-questions/2017-March/091832.html
processes sending messages to a process with a long message queue
are penalized by increasing the number of reductions it costs to send the
message. This is an attempt by the runtime system to allow processes with
long message queues to catch up by slowing down the processes sending the
messages in the first place. The latter bottleneck often manifests itself
in a reduction of the overall throughput of the system.
So - I figured out why they’re called “reductions”. It’s a shorthand for “goal-reductions” (I mean, they’re even shortened to “reds” now …), which is a leftover from when Erlang was written in Prolog. A goal-reduction in prolog is essentially a constituent operation of a larger program. This does literally mean that the processes have a set number of operations they’re allowed to run --- the BEAM VM, though, as we saw last night, is now using this as an abstraction to help support operational spikes. http://erlang.org/pipermail/erlang-questions/2017-March/091832.html
https://github.com/happi/theBeamBook/blob/master/chapters/scheduling.asciidoc#reductions