With a light evaluation it takes more time to communicate than to actually do something, so concurrency is useless.
Use, for instance, p-peaks.
Measure scaling up to the number of threads the computer admits.

Eliminate authors and acks and third-personize references.

Think about new title, more adequate for EvoStar.

Please revise after submission; I turned it in early to not miss the deadline, but if there's some typo or big error we should be able to submit it again. Please do so now.

After the initial proof of concepts, I think this one should focus on scalability and its limits.

• Max number of threads that can be used
• How to balance different types of threads: mixers, reproducers
• How does the number of evaluations and population size per run affect the solution.

Any other thought?

With adaptive or fixed batch size, and measure time and scaling with number of threads.

Check other pool-based and concurrent implementations, including Erlang, Scala, and others like that. Maybe test Go (for speed)

I have started with the de-anonymization of the paper for the camera-ready version which is due by February 11th.

Things done in 20eedbb

• Adding authors names respecting the order that @JJ established on paper submission.
• De-anonymization of all references
• De-anonymization of acknowledgments where I have added the project AMED.

Things TODO:

• Add the institution of Sergio Rojas.
• Double-check if de-anonymization is OK.
• Fixing reviewers comments ?

There's a Data::MessagePack module we can use for that.