[Haskell-cafe] Best Actor system?

[Carter Schonwald]

For throughput base stuff, a careful mix of Some of the libs and tools that
simon marlow espouses in his lovely book will get you very far. Which is
very different from actors models as folks here will assume you mean.

So just use asynch, monadpar, Ryan newtons concurrency libs, and a few
other things.   Ghc itself has a work stealing scheduler deque for sparked
computations!

On Friday, March 28, 2014, james <james at mansionfamily.plus.com> wrote:

> (Isn't it nice to be on a list where peopel top-post? ;-))
>
> Actually I already have Haskell-like code at work where I have actor-like
> processing with
> (event, state) -> (state', actions) and these are mostly pure. And I like
> the model.
>
> I'm NOT looking for spreading over boxes.  What I'm interested in is
> optimisation of the flow of control:
>  - if an actor has a deep queue of input events, I want it to spin
> in-cache efficiently.
>  - if an actor makes an RPC-like transaction against a dormant peer, then
> I want the flow of control
>   on the bound thread to go from one to the other and back, and not result
> in general scheduling
>  - I want the performance of general messaging to be somewhat like that of
> the work-stealing
>   pool we see working well in Akka and JActor
>
> I would be surprised if general LWP scheduling will really be up to it, in
> terms of competing,
> particularly in the case of RPC interactions or pipelines where we'd
> really want to stay cache-hot
> for either the code (for an actor spinning on a deep queue) or the data
> (for a pipeline or RPC).
>
> I'm also interested in terms of how a channel can effectively (and
> efficiently) handle messages where
> the channel is carrying a union of message types that can evolve as the
> system is built.
>
> I'm quite happy to do explicit networking between processes in different
> NUMA zones or on
> different hosts.
>
> James
>
> (Not made my mind up about Erlang - I really like per-actor GC tho.  Will
> try to play with
> Nimrod sometime)
>
> On 27/03/2014 22:34, amindfv at gmail.com wrote:
>
>> Unfortunately I can't help with recommending an actor library. I think
>> peoples' responses of "you should never want to do that" are, um, unhelpful.
>>
>> That said, i've written both haskell and erlang professionally, and never
>> had a need for actors/message passing in haskell. It may be the wrong tool
>> for most haskell jobs.
>>
>> The main things erlang-style concurrency gets you are
>>  - lightweight threads (in haskell by default -- 'forkIO' creates
>> lightweight threads)
>>  - limited shared mutable state (haskell's pure)
>>  - spreading computation over cores (in haskell you want parallelism not
>> concurrency -- check out the Par monad)
>>  - computation over boxes (see distributed-process)
>>
>> To do "message passing", check out MVars (and later, STM)
>>
>> Tom
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140328/8ca826e5/attachment.html>