RE: [Haskell-cafe] Haskell and concurrency
On 25 June 2004 11:52, Graham Klyne wrote:
Anyway, I was wondering if any of the work on concurrent Haskell or concurrent functional programming addresses similar systems or ideas, in which implementation/hardware concurrency is decoupled from application concurrency requirements, and particularly with a view to applications requiring very low-overhead fine-grained concurrency?
Concurrent Haskell is designed to provide exactly the kind of lightweight concurrency you're after. It won't be as quick as a custom application-specific threading model in the way you describe, but it's a *lot* faster than using one OS-thread for each thread in your system. And if you find it to be still too slow for your application, we know of several ways to speed it up... Cheers, Simon
On Fri, 25 Jun 2004, Simon Marlow wrote:
Concurrent Haskell is designed to provide exactly the kind of lightweight concurrency you're after. It won't be as quick as a custom application-specific threading model in the way you describe, but it's a *lot* faster than using one OS-thread for each thread in your system.
And if you find it to be still too slow for your application, we know of several ways to speed it up...
That's exciting. I am currently working on a web-appserver framework that relies on concurent Haskell (hence all my postings to the list about concurrent haskell issues). My theory is, given that you were able to achieve ~1000 requests/second in 2000, I should be able to serve 10k HTTP requests per second on a regular modern beige box. (~5m unique users at 1 visit/day 10 clicks per visit 10 request per click). If I need less than 5k of server state per visitor then I can operate a fairly substantial web site on e.g. a 32GB Dell PowerEdge for under $50k ($.01/user)! http://configure.us.dell.com/dellstore/config.aspx?c=us&cs=555&l=en&oc=PE7250PAD&s=biz I currently have working: * ACID semantics on an abstract serializable state Constraints: * each request must encapsulate the entire transaction * requests and state must be instances of Read/Show * state must fit in memory (though this is looser than it appears) * in order execution of all sideeffects * multiple sideeffect queues * at least once execution of all sideeffects * very basic HTTP serving framework for these apps (SMTP framework coming soon) * a basic relational database (not yet serializable) that will eventually be used as a concrete state implementation I am now working on an application to run on the framework and use these features. I'll post when the design is more proven and its time to reach those performance levels. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com
participants (2)
-
S. Alexander Jacobson -
Simon Marlow