[erlang-questions] Erlang beginner questions

[Dan Gudmundsson]

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.

/Dan

On Wed, Apr 13, 2011 at 9:06 PM, H. Diedrich <hd2010@REDACTED> wrote:
> Welcome!
>>
>> 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
>> a
>> 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
>> the
>> processes that are running in that VM on the individual machine.
>
> Right.
>>
>> 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?
>
> Absolutely.
>>
>> 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.
>
> Henning
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>