On Wed, Aug 4, 2010 at 12:05 PM, Lee Spector <lspec...@hampshire.edu> wrote:
> 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. > 8gb of ram seems kinda low to me for this kind of microbenchmark, especially when running 16 or 48 cores. But I'm no expert. As a far-fetched comparison when I played around with Aleph on 8-core box, doing nothing but hitting the server as fast as possible ate up 2gb of RAM. Seems like there was less allocation there than here (I couldn't even serve more than 20k reqs a second much less 1e6). Why not just replace burn with a large number of arithmetic operations? Memory issues have a less chance of coming into play then. David -- 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
