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?
I'd be interested in seeing benchmarks on this, but I do think that
you'll be better off just spawning a lightweight thread per task,
rather than first wrapping it in some data structure as a work
item, then putting it in a queue, then popping items of the queue
into threads. Seems that doing it that way would just be
duplicating work.
good idea, thanks, I will try..
Fawzi
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
