Fawzi Mohamed wrote:
Il giorno Apr 14, 2007, alle ore 2:45 PM, Sebastian Sylvan ha scritto:
I think you should probably consider the extremely lightweight forkIO threads as your "work items" and the GHC runtime as your thread pool system (it will find out how many threads you want using the RTS options and distribute it for you). If you're worried about memory efficiency you can tweak the initial stack sizes for threads etc. using runtime options.
It's still true that you don't want to fork off trivial computations in a separate thread, BUT that's true for manual work item queues as well (you'd want each work item to be a substantial amount of computation because there is overhead per item). E.g. if you have a list you might not want one thread per element (and you wouldn't want one work item per element either) if the per element tasks are fairly trivial, so you'd first group the list into chunks, and then let each chunk be a work item ( i.e. spawn a forkIO thread to process it).
yes, but to build the optimal chunk size one would like to know the number of working threads. So again, any way to know it at runtime? or it is a bad practice to ask?
There's no way currently, but it would be a useful thing to have. Cheers, Simon