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
(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@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe