Eh, the above should just parallelize working with a single big population. It's not partitioned as far as making-the-cut is concerned, nor crossover (given that each thread adds its M crossover-generated entities by reference to the whole pool of survivors from the previous round). The only constraint the above scheme imposed, in fact, was to force the population size to be divisible by the number of cores, which could be relaxed with the only consequence being a mildly underutilized core (whichever got fewer than the others in its subpopulation). If you have dynamics involving subpopulations that are subjected to separate fitness cuts, reproductively isolated, or what-have-you, that just seems to afford more scope for parallelizing without the order of execution of particular bits of stuff on particular threads affecting things.
On Sat, Dec 28, 2013 at 3:54 PM, Lee Spector <lspec...@hampshire.edu> wrote: > > On Dec 28, 2013, at 3:11 PM, Cedric Greevey wrote: > > > Adding to the above, in the specific context of genetic programming, I'd > suggest dividing the population into N subsets, one per core, and trialling > them in parallel to generate fitness scores; then parallel-mergesort to get > a ranked order; then (apply map vector (partition (/ num-to-keep num-cores) > (take num-to-keep sorted-population))) to cull all but the best num-to-keep > and distribute them across N new subsets with each subset a representative > sample of the range of fitness scores (so any correlation between trial > speed and fitness won't make some populations slow and stop), then apply > any recombination/crossovers to generate, say, M new genomes in each subset > (parallel, uses the static data from the previous round and per-thread > PRNGs to decide which pairs of survivors to use to make offspring added to > that thread's subpopulation), then apply mutation (parallel, each thread > mutates its own subpopulation), then next trial... No > thread-order-of-action dependencies this way. Snapshot once a round by > saving the subpopulations and per-thread PRNG internal states right before > each fitness trial phase. Snapshot should evolve deterministically if > restored with the same values for num-to-keep and num-cores and whatever > other parameters. Last snapshot before crash should crash the same way > every time. > > Some of what you're suggesting would have implications for evolutionary > dynamics. Maybe good, maybe bad, some related to things that I and others > have studied (e.g. various schemes for working with subpopulations), and > some maybe incompatible with other experimental things that I may be > working with. I'm a researcher in this area, so I do care about and have > tried related things for various reasons, but I don't want my > search/evolution algorithm design to be driven by inadequacies of my > programming environment (e.g. difficulties in finding sources of crashes). > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
