Just out of interest (and I'm not trying to be combative here, I'm genuinely curious) - it seems from many of your posts here that this is a serious pain point for you. Why not just use another lisp? High-performance numeric programming doesn't seem like Clojure's strong point and the error handling is clearly difficult for you - why not some CL variant? Do other benefits of Clojure compensate for these problems?
On 29 December 2013 12:42, Lee Spector <lspec...@hampshire.edu> wrote: > > 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. > -- -- 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.
