On Jan 31, 2013, at 10:15 AM, Chas Emerick wrote: >> >> 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: >> > > 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.
FWIW I wrote the "burn" benchmark because "lots of intensive list manipulation" is at the heart of our real applications, and that seemed to be a nicely minimal way to see how that could scale across cores. Our real applications may indeed raise other issues too, but getting "lots of intensive list manipulation" to scale well is bound to be good. FWIW the "full-application benchmark" that Josiah posted was made deterministic in a way that means that big chunks of our code won't actually be executing. The system generates and interprets lots of "Push" programs, and if I recall correctly the benchmark hardcodes all of the Push programs to be the same constant program, meaning that not all of the Push instructions will run, etc. It'd be trickier to get the "real" mix of instructions in a way that makes for an easily reproducible benchmark, and this benchmark is at least testing the basic interpreter and population-level infrastructure. If we can get this to scale reasonably then we could try to see how much that helps under more-completely "real" conditions. -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.
