All, I have a simple Haskell P2P library that I've been playing with in simulations of 20 to 600 nodes. To run the simulation there is a Haskell thread (forkIO) for every node in the system, one that starts up all the nodes and prints the info (so prints aren't mangled), and one that acts as the router. Before its mentioned - I understand the best way forward would be to refactor the code into IO-less 'algorithm' sections and other sections that perform the needed IO when I'm not simulating. I know this would allow me to declare what order each node runs in and would free me from the scheduler. I'd like to do that if its practical... but! None-the-less, here I am saying that there are many interesting little simulations that could be done without refactoring and the correctness isn't altered by the order of operations (not if the nodes behave properly, the slight variation is actually a good test). What I would like to know is are there any plans for GHC to incorporate user-definable scheduler? It would be useful in numerous instance beyond this poor example; I know user scheduling was briefly mentioned in Li's paper but haven't seen or heard of any interest from others since then. Thomas
Thomas You can build your own scheduler very easily using what is already there. As with any simulation the two things that you need to capture are dependency and resource contention. Haskell does both the dependency stuff beautifully and the resource contention. Using STM you can even get nice compositional properties. All you really have to take care of is how time progresses (if that is the sort of simulation you are in to). Yes, refactor the code, choose an appropriate (monadic) framework to run it in and build a consistent logging/monitoring/measuring model into it - then things work great. Cheers Neil On 9 May 2009, at 00:22, Thomas DuBuisson wrote:
All, I have a simple Haskell P2P library that I've been playing with in simulations of 20 to 600 nodes. To run the simulation there is a Haskell thread (forkIO) for every node in the system, one that starts up all the nodes and prints the info (so prints aren't mangled), and one that acts as the router.
Before its mentioned - I understand the best way forward would be to refactor the code into IO-less 'algorithm' sections and other sections that perform the needed IO when I'm not simulating. I know this would allow me to declare what order each node runs in and would free me from the scheduler. I'd like to do that if its practical... but!
None-the-less, here I am saying that there are many interesting little simulations that could be done without refactoring and the correctness isn't altered by the order of operations (not if the nodes behave properly, the slight variation is actually a good test). What I would like to know is are there any plans for GHC to incorporate user-definable scheduler? It would be useful in numerous instance beyond this poor example; I know user scheduling was briefly mentioned in Li's paper but haven't seen or heard of any interest from others since then.
Thomas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
properly, the slight variation is actually a good test). What I would like to know is are there any plans for GHC to incorporate user-definable scheduler? What exactly is it that you want from a user-definable scheduler? Do you want co-operative scheduling in your program, or do you want to be able to control the thread-grouping and running order in the GHC runtime? More details of your requirements would help -- I can't quite make out what you need from your email.
Thanks, Neil.
On Sat, May 9, 2009 at 6:28 AM, Neil Brown
properly, the slight variation is actually a good test). What I would like to know is are there any plans for GHC to incorporate user-definable scheduler?
What exactly is it that you want from a user-definable scheduler? Do you want co-operative scheduling in your program, or do you want to be able to control the thread-grouping and running order in the GHC runtime? More details of your requirements would help -- I can't quite make out what you need from your email.
I would like to alter the running order. For example, the router thread should be ran in between every other thread - its the other threads goal in life to send messages so there's probably one ready. Additionally, the older threads should gradually become higher priority (so they run more frequently and/or for longer than new threads). As I acknowledged, this simulation is a poor example, but what this would give me is a bias toward the nodes in the DHT and away from the hundreds of nodes sending join messages that will have high contention and be dropped (there will always be progress, but as with STM there is lots of retrying involved). Thomas
participants (3)
-
Neil Brown -
Neil Davies -
Thomas DuBuisson