Concurrent individual evaluation

[Joe]

Hi,

I am implementing multi-threaded evaluation of individuals; my
motivation is concurrent evaluation across a pool of distributed
machines on the basis that genetic operations are fast relative to
fitness evaluation which in my case is long-running and will benefit
from parallelism. My thoughts on implementing this are below: would be
keen on any feedback/advice or if you are close to implementing this
yourselves I could save myself some hacking...

(1) RunManager.updateBestProgram would need to implement thread pool,
queue CandidateProgram.getFitness tasks, and block until all are
completed, then scan for best fitness/program and add stats.
Incidentally, if this were a protected method I could override it in
eg ConcurrentRunManager, but will now subclass and c&p the entire
run() method. Also, could I suggest renaming to evaluatePopulation?
Perhaps a better, but larger, change would be Strategy pattern for
evaluation?
(2) As there are no statistics or lifecycle events within this (tight)
evaluation loop, no need to make these classes thread-safe (?)
(3) Model/GEModel need to be made thread-safe; locking for single
thread access would defeat the purpose, and creating thread-local
(pooled) Model instances would be overkill just for evaluation, so my
thoughts are to have thread-local evaluation objects (ie,
JavaEvaluator, REvaluator objects, plus all supporting data etc)
encapsulated in their own ModelEvaluator class.

Any thoughts?

[Tom Castle]

With regards to whether you should hack this up yourself or wait, it
really depends on how urgently you need it. It will definitely be in
the next significant release (1.2), although I cannot say exactly how
long that will be. At a guess I would expect 6-8 weeks. As you
mention, I do intend to use something along the lines of a strategy
pattern which will make the different (concurrent, distributed,
sequential etc) evaluation approaches pluggable. Exactly what you're
after really!

(1) The updateBestProgram method is a hangover from a (terrible) older
approach to fitness evaluation, and I'll be happy to see it disappear
with the new evaluation implementation. Your hack sounds like that
could work. You'll find that generally the classes in the core package
aren't designed to be extended, although it is good to see that you're
finding ways to hack on these features that haven't got built-in
support yet.

(2) That's correct.

(3) Definitely. The getFitness method in the model is obviously the
weak point, so yes you need to ensure concurrent access.

[Joe]

Thanks Tom. My timeframes are indeed short - I'll push ahead as would
like to complete this weekend, then compare notes when you release.

One other problem I'm facing is that I'd like to extend
GECandidateProgram to add other evaluation statistics (eg, beyond just
a single fitness value, the result of out-of-sample testing runs and
features of the data mining processes used for evaluation) but all of
the initialisation operations have GECandidateProgram hardcoded (quite
reasonably). Would you consider using generics (overkill for most
users?) or a factory class for the init/breeding operators, which
would be sensibly defaulted, to assist those wanting to subclass
programs?

Regards