ka, I ran some more tests, including partition-work and your version of fac. I also ran some code from http://shootout.alioth.debian.org in both C and Java.
On these 10-element sequences, partition-work seems to be a few tens of milliseconds slower than partition-all. It does look generally useful though; I'll run some more tests with it. Your version of fac doesn't change the performance characteristics on the Mac much: two cores are almost twice as fast as one, but three or four result in single-digit percentage gains. My fac was 8% faster on four cores instead of two. Yours was 1% faster. I also tried with a 12- element sequence to try to ensure that all the cores had the same amount of work. In that situation, four and two were even closer. I ran the Java versions of the Mandelbrot and spectral norm benchmarks from the above-linked site, as those appeared to keep all the cores busy. Java versions of both run nearly twice as fast on the Mac Pro as my dual-core laptop, which is in line with expected results on a trivially parallel problem (the laptop is slightly faster per-core). The problem here seems to be Clojure-specific. There's some sort of overhead here that keeps the CPUs busy (top reports 390%), but very little extra desirable work is actually getting done. If this is indeed a Clojure problem, I'm happy to try to help track it down. I'm not very familiar with the profiling and monitoring tools for the JVM, so a pointer in the right direction there would be appreciated. -- 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
