Most models do not honor ParallelEval

[spakin]

Problem

Most of the models defined in models.go evaluate the fitness function sequentially, even if ParallelEval is set to true. From what I can tell from inspecting the source code, this applies to ModDownToSize, ModRing, and ModMutationOnly. This poses a problem because SPSO, DiffEvo, and OES all hard-wire ModMutationOnly as their model.

Reproducer

Here's a reproducer:

pareval.zip

Run first with the ModRing stanza commented out then with the ModGenerational stanza commented out and observe the performance difference. Here's what I measured:

ModGenerational

$ time ./pareval 
Best fitness at generation 0: -0.348941
Best fitness at generation 1: -0.757410
Best fitness at generation 2: -0.960569
Best fitness at generation 3: -0.960569
Best fitness at generation 4: -0.968049
Best fitness at generation 5: -0.968049
Best fitness at generation 6: -0.968049
Best fitness at generation 7: -0.968049
Best fitness at generation 8: -0.968049
Best fitness at generation 9: -0.983219
Best fitness at generation 10: -0.999640

real	0m42.007s
user	0m0.014s
sys	0m0.000s

ModRing

$ time ./pareval 
Best fitness at generation 0: -0.522594
Best fitness at generation 1: -0.928452
Best fitness at generation 2: -0.928452
Best fitness at generation 3: -0.928452
Best fitness at generation 4: -0.935102
Best fitness at generation 5: -0.935497
Best fitness at generation 6: -0.996757
Best fitness at generation 7: -0.996757
Best fitness at generation 8: -0.996757
Best fitness at generation 9: -0.996757
Best fitness at generation 10: -0.998831

real	7m32.042s
user	0m0.050s
sys	0m0.033s

Resolution

Unfortunately, this may be a difficult problem to fix. As far as I can tell, a Model has no access to a GAConfig and therefore can't determine if ParallelEval is set to true or false. If nothing else, others can reference this issue if, like I, they find that SPSO, DiffEvo, and OES run substantially slower than GA when given a computationally intense fitness function.