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.  <div>
<br></div><div>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! <span></span><br><br>On Friday, March 28, 2014, james <<a href="mailto:james@mansionfamily.plus.com">james@mansionfamily.plus.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Isn't it nice to be on a list where peopel top-post? ;-))<br>
<br>
Actually I already have Haskell-like code at work where I have actor-like processing with<br>
(event, state) -> (state', actions) and these are mostly pure. And I like the model.<br>
<br>
I'm NOT looking for spreading over boxes.  What I'm interested in is optimisation of the flow of control:<br>
 - if an actor has a deep queue of input events, I want it to spin in-cache efficiently.<br>
 - if an actor makes an RPC-like transaction against a dormant peer, then I want the flow of control<br>
  on the bound thread to go from one to the other and back, and not result in general scheduling<br>
 - I want the performance of general messaging to be somewhat like that of the work-stealing<br>
  pool we see working well in Akka and JActor<br>
<br>
I would be surprised if general LWP scheduling will really be up to it, in terms of competing,<br>
particularly in the case of RPC interactions or pipelines where we'd really want to stay cache-hot<br>
for either the code (for an actor spinning on a deep queue) or the data (for a pipeline or RPC).<br>
<br>
I'm also interested in terms of how a channel can effectively (and efficiently) handle messages where<br>
the channel is carrying a union of message types that can evolve as the system is built.<br>
<br>
I'm quite happy to do explicit networking between processes in different NUMA zones or on<br>
different hosts.<br>
<br>
James<br>
<br>
(Not made my mind up about Erlang - I really like per-actor GC tho.  Will try to play with<br>
Nimrod sometime)<br>
<br>
On 27/03/2014 22:34, <a>amindfv@gmail.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
The main things erlang-style concurrency gets you are<br>
 - lightweight threads (in haskell by default -- 'forkIO' creates lightweight threads)<br>
 - limited shared mutable state (haskell's pure)<br>
 - spreading computation over cores (in haskell you want parallelism not concurrency -- check out the Par monad)<br>
 - computation over boxes (see distributed-process)<br>
<br>
To do "message passing", check out MVars (and later, STM)<br>
<br>
Tom<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
Haskell-Cafe mailing list<br>
<a>Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>