[erlang-questions] Keeping massive concurrency when interfacing with C
Wed Oct 5 10:26:10 CEST 2011
On Wed, Oct 5, 2011 at 12:38 AM, Richard O'Keefe <ok@REDACTED> wrote:
> A further clarification on what Joe wrote about hot loading:
> Whatever the current Erlang system actually does, the overhead of remote
> calls need in principle be no more than the overhead of dynamic dispatch
> in a language like C++.
> That overhead is actually surprisingly high (and yet people *willingly*
> write Java, go figure). There is an indirect cost to the indirection,
> namely that dynamic calls can't be inlined. For C++ there is an answer:
> link-time analysis can find calls (often lots and lots of them) that
> don't actually need to be polymorphic (e.g., because the declared class
> turns out not to have any subclasses that override the method in question)
> and those calls can be inlined after all. In languages which allow new
> code to be added at run time (like Java and Erlang) it's not that easy.
> Some years ago I proposed that Erlang could distinguish between
> "detachable" and "non-detachable" parts, so that a group of modules could
> be bound together in such a way that they would have to be replaced _as a
> unit_. The idea has not been taken up because it's very far from being
> Erlang's most pressing problem.
> To John Smith, what on earth does "shocking the yield curve" mean?
> One thing about architecture. Joe raised an interesting question.
> "Now suppose you discover a fault in your software that causes to you
> buy or sell shares at a catastrophically bad rate - what do you do -
> wait for everything to stop before changing the code?"
> My question is, "how could you structure your system so that if it
> TRIES to buy or sell at a catastrophically bad rate it CAN'T?" A couple
> of years ago I came up with an idea for a potential PhD candidate who
> ended up going somewhere else. That was inspired by a true event here,
> where an electricity company cut off supply to a house where there was
> an extremely sick woman who depended on some machine to keep her alive
> (I forget what kind). Needless to say, she died. And of course it was
> one of those stories where the computer noticed the bill hadn't been
> paid recently and sent out a notice to a technician who dutifully went
> out and turned the power off without asking any awkward questions. So
> what can we do to stop that? (The customer had informed the company of
> their special needs.) The answer I came up with turns out to be
> quite similar in spirit to Joe's UBF.
> You have a GENERATOR of actions,
> a CRITIC of actions, and
> an EFFECTOR of actions.
> (Come to think of it, there's a link here to Dorothy L. Sayers' "The
> Mind of the Maker.") The generator of actions receives inputs and
> decides on things to do, but doesn't actually do them. It passes
> its proposals on to the critic, which watches out for bad stuff.
> Things that the critic is happy with are passed on to the effector to
> be carried out.
> In the electricity case, the critic would use rules like
> "If the proposal is to disconnect supply
> and the customer has registered a special need
> and there is no record of a court order
> In the trading case, the critic's rules would say something about the
> amount of money.
Absolutely - move compliance into the software - If traders expose a
bank to too much risk the
trades should be stopped automatically. This might have prevented
(say) the collapse
of Baring bank. There is a trade of between security - (we have to
spend a few CPUs cycles
checking for illegality) and speed here.
If a bank collapses due to trading violations that could have been
detected by software and no
such software was in place I imagine legal action could be taken. So
there should be a strong argument for such software.
> The generator should not rely on the critic; if everything is working
> well you won't be able to tell if the critic is there or not.
> A rejection by the critic indicates an error in the generator
> requiring corrective programming. This is where it gets similar
> to UBF: UBF contract checking isn't there to make good things
> happen normally, it's there to stop bad things happening and make
> sure they're noticed.
> This is one way to use multicore: spend some of the extra cores doing
> more checking.
More information about the erlang-questions