[erlang-questions] Erlang beginner questions
Wed Apr 13 21:13:07 CEST 2011
Depending on the problem, but if you want more raw math power,
physics can be calculated with OpenCL, and by using
that you don't have to write a driver (or nif lib) yourself.
But as always write it in erlang first then go the driver/OpenCL route,
and you have a nice debugged reference implementation as well.
On Wed, Apr 13, 2011 at 9:06 PM, H. Diedrich <hd2010@REDACTED> wrote:
>> This is exactly they type of example I'm looking for, thanks Henning! And
>> I've been thinking I should embed a scripting language like Lua for
>> developers extending things without modifying underlying code, so this is
>> really great find, thanks.
> Be sure to check out other projects re Lua. This was really referred to as
> an example of architecture.
>> Each computer has one instance of the Erlang VM running.
> You can have more, in fact, 2 might make sense and that's what I think might
> be what you want.
>> Each VM can have
>> many processes. Using a linked-in driver essentially treats that C module
>> as an extension of the Erlang VM itself, so if it crashes, so do all of
>> processes that are running in that VM on the individual machine.
>> Does the
>> VM restart automagically, or does it require a manual restart?
> Erlang is made for the VM never to crash and it has an elaborate structure
> on how processes inside the VM restart each other and supervise each other.
> That architecture can span multiple 'nodes'. But when crashing, dying,
> exiting is talked about, in general you want it all to happen 'gracefully'
> and not have to restart the entire VM.
> BUT you could decide to have your C library linked-in to one Erlang VM, with
> very thin Erlang code on top, that talks to another VM (node) and of that
> first one you make sure comes up automatically if the whole VM crashes, e.g.
> due to the C stuff, while the second is your main Erlang node.
>> A port driver, on the other hand, is treated as a separate node. If it
>> crashes, it is contained within that node. It is slightly slower than a
>> linked-in driver though. Is it fast enough to implement many messages per
>> second back & forth?
>> By saying it's not quite as fast as a function call
>> I'm assuming you mean a linked-in driver call, right?
> Yes. But also in Erlang proper, sending messages is a tad slower than
> function calls.
>> Essentially a port
>> driver is probably best for implementing hardcore math many times per
>> second, right?
> Many times per second would be "low frequency" and so, especially if you
> must realistically expect crashes, yes.
> erlang-questions mailing list
More information about the erlang-questions