On Oct 11, 2013, at 4:55 PM, Ralf Buschermöhle wrote:
> in order to make it even more complex ... also different multithreaded sized clients would be ... great! :)
That one would be too tough to implement anytime soon.
But as to waiting until the job has all come in: my analysis of the current code suggests that this is NOT what happens.
Slaves can run in one of two modes:
1. "run-evolve mode". Here the slave loads the job into a population, then evaluates them, and if there's more time, does some evolution on that population, eventually returning the revised population as new versions of the original individuals.
2. NOT "run-evolve mode" (the default). Here the slave fires off a new thread each time it reads an individual in, and immediately starts evaluating it. Then it returns all the fitness results together as a group. The downside of this is that if your job size is much larger than your threads, you're doing too much context switching. I can fix that. Also it waits until everything's finished before the fitnesses are returned; this probably isn't that big of an issue in truth. But the upside is that it DOES immediately start processing an individual as soon as one arrives -- it doesn't wait until the job's been loaded.