On Aug 4, 2010, at 11:36 AM, David Nolen wrote: > Have you considered that you're realizing very large lazy sequences and might > be thrashing around in GC ? The parallel versions needs X times the available > memory of the sequential version, where X is the number of concurrent threads > right? > > David
Thanks! I hadn't really thought about that. I realized there'd be a lot of gc -- part of what makes my "burn" reliably slow is all of the allocation -- but I didn't consider how that would affect the concurrency. I don't yet understand what's going on, but I can see how this can be a part of the story. I normally run my real code with -Xmx8000m -XX:+UseParallelGC (more on this below), but I wasn't doing that here. Can anyone suggest a good alternative to my "burn" function that doesn't allocate so much? A lot of the other simple things I've tried end up getting optimized away or have other problems e.g. with potentially shared state. On the current garbage-full test I've just done some runs on my 16-core and 48-core machines with -Xmx8000m -XX:+UseParallelGC to see what happens (I didn't try the macbook as that'd be too painful). It looks like the gc issues may be part of the problem but maybe not all of it and in any event I'd like to deal with this condition because a lot of my real code also generates a fair amount of garbage. So here's what I get: 16-core machine: 4 sequential burns: "Elapsed time: 2265.63 msecs" 4 sequential burns: "Elapsed time: 1414.172 msecs" 4 sequential burns: "Elapsed time: 1475.195 msecs" 4 burns via pmap: "Elapsed time: 525.457 msecs" 4 burns via pmap: "Elapsed time: 480.503 msecs" 4 burns via pmap: "Elapsed time: 478.471 msecs" 4 burns via futures: "Elapsed time: 480.264 msecs" 4 burns via futures: "Elapsed time: 471.975 msecs" 4 burns via futures: "Elapsed time: 431.493 msecs" 4 burns via agents: "Elapsed time: 457.011 msecs" 4 burns via agents: "Elapsed time: 1280.258 msecs" 4 burns via agents: "Elapsed time: 1666.843 msecs" 16 sequential burns: "Elapsed time: 15556.021 msecs" 16 sequential burns: "Elapsed time: 5842.776 msecs" 16 sequential burns: "Elapsed time: 5614.196 msecs" 16 burns via pmap: "Elapsed time: 877.268 msecs" 16 burns via pmap: "Elapsed time: 888.215 msecs" 16 burns via pmap: "Elapsed time: 877.342 msecs" 16 burns via futures: "Elapsed time: 834.906 msecs" 16 burns via futures: "Elapsed time: 831.864 msecs" 16 burns via futures: "Elapsed time: 850.556 msecs" 16 burns via agents: "Elapsed time: 829.017 msecs" 16 burns via agents: "Elapsed time: 842.76 msecs" 16 burns via agents: "Elapsed time: 838.963 msecs" 48 sequential burns: "Elapsed time: 14384.727 msecs" 48 sequential burns: "Elapsed time: 14178.273 msecs" 48 sequential burns: "Elapsed time: 14354.98 msecs" 48 burns via pmap: "Elapsed time: 2519.251 msecs" 48 burns via pmap: "Elapsed time: 2529.945 msecs" 48 burns via pmap: "Elapsed time: 2485.531 msecs" 48 burns via futures: "Elapsed time: 2499.972 msecs" 48 burns via futures: "Elapsed time: 2531.965 msecs" 48 burns via futures: "Elapsed time: 2485.508 msecs" 48 burns via agents: "Elapsed time: 2481.373 msecs" 48 burns via agents: "Elapsed time: 2517.313 msecs" 48 burns via agents: "Elapsed time: 2528.774 msecs" That has a few weird data points (WTF with 4 burns via agents?), but overall things look better. Still not the speedups I'd like but okay. On the 48 core machine things are weirder and worse though: 48-core machine: 4 sequential burns: "Elapsed time: 3066.039 msecs" 4 sequential burns: "Elapsed time: 2033.993 msecs" 4 sequential burns: "Elapsed time: 1922.196 msecs" 4 burns via pmap: "Elapsed time: 709.523 msecs" 4 burns via pmap: "Elapsed time: 718.148 msecs" 4 burns via pmap: "Elapsed time: 672.127 msecs" 4 burns via futures: "Elapsed time: 636.268 msecs" 4 burns via futures: "Elapsed time: 616.002 msecs" 4 burns via futures: "Elapsed time: 705.916 msecs" 4 burns via agents: "Elapsed time: 651.217 msecs" 4 burns via agents: "Elapsed time: 653.037 msecs" 4 burns via agents: "Elapsed time: 624.109 msecs" 16 sequential burns: "Elapsed time: 8132.904 msecs" 16 sequential burns: "Elapsed time: 8030.799 msecs" 16 sequential burns: "Elapsed time: 8027.839 msecs" 16 burns via pmap: "Elapsed time: 8963.517 msecs" 16 burns via pmap: "Elapsed time: 10136.282 msecs" 16 burns via pmap: "Elapsed time: 7886.898 msecs" 16 burns via futures: "Elapsed time: 8408.447 msecs" 16 burns via futures: "Elapsed time: 8912.095 msecs" 16 burns via futures: "Elapsed time: 9447.909 msecs" 16 burns via agents: "Elapsed time: 9111.512 msecs" 16 burns via agents: "Elapsed time: 8193.977 msecs" 16 burns via agents: "Elapsed time: 8608.792 msecs" 48 sequential burns: "Elapsed time: 29589.368 msecs" 48 sequential burns: "Elapsed time: 24645.144 msecs" 48 sequential burns: "Elapsed time: 24679.677 msecs" 48 burns via pmap: "Elapsed time: 3632.802 msecs" 48 burns via pmap: "Elapsed time: 3265.142 msecs" 48 burns via pmap: "Elapsed time: 3152.638 msecs" 48 burns via futures: "Elapsed time: 2975.106 msecs" 48 burns via futures: "Elapsed time: 2753.874 msecs" 48 burns via futures: "Elapsed time: 2514.689 msecs" 48 burns via agents: "Elapsed time: 2408.934 msecs" 48 burns via agents: "Elapsed time: 2255.151 msecs" 48 burns via agents: "Elapsed time: 2297.035 msecs" For 4 burns things look good, but for 16 burns we again have a case in which concurrency always loses over sequential execution or is about the same. For 48 burns, however, things look good again. I also note, however, that comparing between the two machines my 48-core isn't buying me anything over my 16-core. Hmm! -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- 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
