On Dec 28, 2013, at 4:46 PM, Cedric Greevey wrote: > 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.
Ah yes, I now see that you weren't operating on the subpopulations in ways that would change the global behavior. Sorry I read that too quickly, and I do appreciate the suggestions. You've specified some other things that aren't quite compatible with the ways we often do things (e.g. about how and when selection works), but those could be tweaked and in fact we already do many of the things that you suggest, with concurrent fitness evaluation using thread-local RNGs (although we sometimes actually see mysterious bad performance from this -- which led to this thread: https://groups.google.com/forum/#!searchin/clojure/abysmal/clojure/48W2eff3caU/p12kY9D8d1cJ). The question is, would it be worth it to take the time to ensure that all of the RNG handling allows complete repeatability, and add the snapshotting (which presumably has both development and runtime costs), and add whatever would be needed to restart from a snapshot? Maybe, but since I generally don't actually care about repeatability, it seems like the long way around. If I could instead get Clojure to dump the values of locals when an exception is raised -- which is already available in some IDEs but not more generally -- then I wouldn't have any other reason to do this. Thanks, -Lee -- -- 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.
