I think that a compile-time switch that sets the maximum number of threads would be a good solution. This way, you could compile Perl with support for 8 threads on an 8 core processor, and have it be used completely.
Each thread could get one item to start with, and as it finishes, it could get an additional item. If it's just running a built-in function on the list, then each thread could be given 1/n of the list (where n is the number of threads). Otherwise, Perl could time the items and detect about how many would be good to send based on the time.
Perl would still need to get data back from the threads to give back to the core, so sending data shouldn't be a problem either. But I've never used threads, so I may be off. | [reply] |
I don't think a compile time switch is a good solution, that's far too restricitve. Especially since quite a few people do not compile their perl!
Besides what you say assumes that it's always OK to use up all the power of the machine and also it's the way you would want to use the paralelization for the computationaly expensive tasks. In case the operation you want to do with the element of the list spends more time waiting for some data then you will want to use more threads. Eg. if you wanted to test the conectivity to the computers specified in the list you will spend most time waiting for the pings to return or time out, not computing anything. So you would want to create quite a few more threads than if you just need to use all the CPUs your box has.
-
| [reply] |
| [reply] |