On Sat, Dec 31, 2011 at 2:36 PM, Jorge <jo...@jorgechamorro.com> wrote: > > tThreads(seconds): 0.535, tProcs(seconds): 0.573, ratio:0.933 > > Perhaps I'm doing it wrong ? > Could you run it on other unixes and post the results ? >
I used "-O3 -pthread" for CFLAGS and got the following results on two vastly different Linux Xen vhosts, both of which reported 2 CPU cores: tThreads(seconds): 0.271, tProcs(seconds): 0.294, ratio:0.920 tThreads(seconds): 0.700, tProcs(seconds): 0.716, ratio:0.978 And this on an older local MacOS laptop w/ 4 cores: tThreads(seconds): 0.939, tProcs(seconds): 0.961, ratio:0.977 So yes, I think it's fair to say that for the workload measured by the benchmark, threads is probably slightly faster on the tested hosts. But I think given the facts that (a) the timings include pthread_create()/pthread_join() in the threads and fork()/waitpid() in the procs case, and (b) the calculation in each thread completes very very quickly, most likely it's the thread/proc spawn/cleanup stuff that's making a different, and I imagine thread do create/join faster than fork/waitpid in the general case. On the other hand, if I modified kPI to be 5e7 to give them more CPU work to do per thread/proc invocation, I get the following on my MacOS laptop: tThreads(seconds): 9.482, tProcs(seconds): 9.341, ratio:1.015 On the two linux xen hosts even at 5e8 the threads still came out barely ahead, but then again they're xen hosts, so I'm not sure how relevant they are given the extra layer there... -- Brandon
_______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
