On May 18, 2008, at 2:01 PM, Sean Luke wrote:
> On May 18, 2008, at 4:36 PM, Peter Drake wrote:
>> I was a bit disappointed to read that coevolution is not
>> multithreaded, but I can see how this would be challenging.
>> Perhaps I'll be able to help with that at a later date.
> Coevolution involves a lot of interweaving of evaluations, so yeah,
> multithreading can be challenging. But not impossible.
> Y'know, multithreading is a tricky thing. Over the last few days
> I've been trying to nail down why a non-locking multithreaded
> version of a particular simulation in MASON (ECJ's sister project,
> a multiagent simulator) was *slower* than the single-threaded
> version on a multiprocessor machine. My best guess is that our
> heavy memory usage pattern was a bad case for the memory controller
> of the dual CPU. Oh well.
Someone who knows much more than I about optimization once said that
a cache miss was the worst thing that could happen to a program's
speed. (A branch was the second worst.)
>> Despite the claims in the documentation for ec.Subpopulation,
>> ec.subpop does not appear to work as a default base.
> On CVS it does now. :-) The default base is "ec.subpop".
It works, but only for subpopulation 0. Specifically, if I
ec.subpop.size = 500
I get this message:
Subpopulation size must be an integer >= 1.
>> ec.Evaluator doesn't appear to have a default base, which makes
>> for some redundancy in the parameter file.
> Where was the redundancy? I missed it.
> Evaluator wouldn't have a default base because there's only ever
> one of them -- it's a singleton.
# (more precisely, ec.coevolve.MultiPopCoevolutionaryEvaluator)
eval.problem = orego.gp.MostC3s
# There is some redundancy because these must be specified for each
# Number of opponents for judging each individual, chosen from the
other population randomly
# (num-rand-ind), from the best (num-elites), or by selection (num-ind)
eval.subpop.0.num-rand-ind = 6
eval.subpop.0.num-elites = 1
eval.subpop.0.num-ind = 0
# How to choose individuals from each population for evaluation
# (A tournament of size 1 is equivalent to random selection)
#eval.subpop.0.select = ec.select.TournamentSelection
#eval.subpop.0.select.size = 1
# The same information for the other subpopulation
eval.subpop.1.num-rand-ind = 6
eval.subpop.1.num-elites = 1
eval.subpop.1.num-ind = 0
eval.subpop.1.select = ec.select.TournamentSelection
eval.subpop.1.select.size = 1
Finally, I'm also getting these warnings:
In function set f0 for the GPTreeConstraints tc0, no *nonterminals*
are given with the return type move which is required by other
functions in the function set or by the tree's return type. This may
or may not be a problem for you.
Initializing Generation 0
A GPNodeBuilder has been requested at least once to generate a one-
node tree with a return value type-compatable with a certain type;
but there is no NON-TERMINAL which is type-compatable in this way.
As a result, the algorithm was forced to use a TERMINAL, making the
tree larger than requested, and exposing more child slots to fill,
which if not carefully considered, could recursively repeat this
problem and eventually fill all memory.
class ec.gp.koza.HalfBuilder can't find a terminal type-compatable
What can/should I do about these? My intent is that ncMove is a
terminal. MoveNode extends ERC.