#7606: Stride scheduling for Haskell threads with priorities ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by njd): I'd like to add a word of caution to the inclusion of any form of priority/weighted scheduling into GHC at this time. Scheduling (unless it discards work) does not, a priori, change the total amount of work that has to be done, just its order. Such scheduling strategies don't create computational power, they just distribute the "disappointment" of not being first... This would imply that all of the timing changes reported in this thread are the result of interactions with other resources - different patterns of memory access, garbage collection etc. The community already recognises these sort of performance couplings and there several mechanisms (at a higher level) that can be used to manage the inevitable performance trades. I strongly believe that adding differential scheduling at this time will be, overall, counter productive to GHC's RTS development. It will create a new class of performance artefacts that will require resources to investigate. Time will be spent pushing trades around, chasing the proverbial bubble under the wall paper around and around. Please don't get me wrong, I am highly appreciative of Edward's efforts. The more overhead we can reduce in the scheduling, the better. If we want to start looking at more complex differential treatment of the allocation of supply (cpu cycles) to demand (task steps) then we need to consider the issues of how that trade interacts with the others. And how the overall trading space is going to manifest itself in terms of end-user goals. We also need to come up with a sensible approach of how to discard computational demand (load shedding) when the "system" becomes "excessively" infeasible to schedule to met those goals. Fortunately there are approaches to this (stuff I've been involved with in data networks for many years) - and Haskell's operational has all the right hooks in to do this. Interested PhD students, do get in touch.... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7606#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler