On Jan 31, 2013, at 9:23 AM, Marshall Bockrath-Vandegrift wrote: > Chas Emerick <c...@cemerick.com> writes: > >> The nature of the `burn` program is such that I'm skeptical of the >> ability of any garbage-collected runtime (lispy or not) to scale its >> operation across multiple threads. > > Bringing you up to speed on this very long thread, I don’t believe the > original `burn` benchmark is a GC issue, due to results cameron first > reported here: > > https://groups.google.com/d/msg/clojure/48W2eff3caU/83uXZjLi3iAJ > > I that narrowed to what I still believe to be the explanation here: > > https://groups.google.com/d/msg/clojure/48W2eff3caU/jd8dpmzEtEYJ > > And have more compact demonstration benchmark results here: > > https://groups.google.com/d/msg/clojure/48W2eff3caU/tCCkjXxTUMEJ > > I haven’t been able to produce those results in a minimal Java-only test > case, though. > > Then Wm. Josiah posted a full-application benchmark, which appears to > have entirely different performance problems from the synthetic `burn` > benchmark. I’d rejected GC as the cause for the slowdown there too, but > ATM can’t recall why or what I tested, so GC may definitely be a > candidate to re-examine: > > https://groups.google.com/d/msg/clojure/48W2eff3caU/K224Aqwkn5YJ > > Quite looking forward to additional insight...
Yeah, the thread is far too large for me to reasonably digest (and there's inevitably a lot of noise in rounds of microbenchmarking golf ;-) BTW, I just realized I copy/pasted the wrong command for the faster of the Java implementation benchmarks in the previous mail; it used -XX:-UseParallelGC: `java -server -Xmx2g -XX:-UseParallelGC cemerick.burn $THREAD_COUNT` I've not looked at clojush at all; it is AFAICT a complex application in its own right, and I wouldn't know where to start. My understanding is that the `burn` function is considered representative of the bulk of operations in clojush, but I'm happy to assume that that's not the case. There's likely a number of things that go into the results of the `burn` benchmark, nevermind the apparent performance of clojush. Here's what I know: * Two separate implementations (Java and Racket) exhibit very similar multicore performance characteristics. In particular, the Java implementation would not suffer from any particular megamorphic inefficiencies, since no such calls are made in that program. Racket is far more of a black box to me than the JVM, but it does not provide much of any polymorphism at all, so JIT-related issues are presumably not in scope there. * Broadly speaking, heap allocation and its evil twin, GC, sabotages parallelism and performance in general. Functional programming with immutable values has been "made possible" in large part by the gains registered by persistent data structures, structural sharing, lazy evaluation, and so on; without them, we're back to copy-on-write, which is roughly what `burn` represents in grand style. Now, all this digital ink spilled, and just for kicks, I go back to run the Clojure `burn` again (https://gist.github.com/4683413 in a 1.5.0-RC2 REPL started with jvm args of `-Xmx2g -XX:-UseParallelGC`): 1 thread: 38s 2 threads: 32s 4 threads: 23s Hardly a 2x or 4x improvement, but I had previously obtained badly degrading timings corresponding to those in my previous mail. Microbenchmarking sucks. At least I got to twiddle with Racket again. :-P Cheers, - Chas -- -- 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.
