Feature request: ability to use libeio with multiple event loops

Brandon Black blblack at gmail.com
Sat Dec 31 22:38:42 CET 2011

On Sat, Dec 31, 2011 at 2:36 PM, Jorge <jorge at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20111231/b19c721a/attachment.html>

More information about the libev mailing list