>> // just to make sure I understand (some) implications correctly ...
>> Let's assume there is a multithreaded slave with 4 cores with eval.masterproblem.job-size = 1 and eval.masterproblem.max-jobs-per-slave = 8 with a total population of some hundred individuals ...
>> 0. The server fills the queue of the client (completely) with 8 jobs
>> 1. The slave would evaluate 4 jobs concurrently
> From my reading of the code I think at present the slave would evaluate all 8 jobs concurrently. No, I don't think ignoring evalthreads is optimal either. But it'll take me a little bit to fix it.
>> 2. After finishing the first job (the others take significantly longer) the slave sends the result to the server and starts processing the 5. job in the queue
> At present the slave has to return the individuals in the order they arrived. If individual 0 finishes first it'll be returned immediately. But if individual 4 finishes first it has to wait until the others are returned first.
> I know what you're trying for -- perhaps a better option for the time being would be to set the job size to 1, and create FOUR ECJ slave processes on your slave machine. Then they'd be totally asynchronous.
Actually I do it this way.
The only problem in my case is that the memory requirements for each slave are high (i have a kind of a database in memory, caches etc.). In general the memory can't be large enough ;)
** from the next posting **
> Let me revise this a bit more in the context of your assumption. I'd say that at present eval.masterproblem.job-size defines the degree of concurrency in a slave (as well as the job packing), and eval.masterproblem.max-jobs-per-slave is meant to keep the network buffer warm.
Ok, so the "only" thing to be changed in the code is that slave (and master) will send to individuals asynchronously so that a multithreaded client does not wait until the last individual of a job was processed but starts directly with a new one.
This would be great. Please let me know if and how I can help ... :)