On Tue, Apr 13, 2010 at 03:26:19PM +0200, Gabriel Kerneis <[email protected]> wrote: > See the attached script. You might need to tweak it a bit (especially > the cpufreq-set call) but otherwise, it automates completely the > benchmark (provided you have the expected tools installed).
After fixing my multiple issues, I can now essentially reproduce your findings. This is basically my version of your diagram: http://data.plan9.de/xt0.png http://data.plan9.de/xt1.png this is when i use add instead of mod (major change is in overall time, as libev does it's syscalls at another time than libevent): http://data.plan9.de/yt0.png http://data.plan9.de/yt1.png And just for fun, this is using select (showing that the management code internal to libev is faster, which is good for my sense of reality, as it is much simpler than the one in libevent2): http://data.plan9.de/zt1.png (note: double-logarithmic) Effectively, there is now little (practical) performance difference between libev and libevent, unless one has a really high number of fds to attend to. Thanks for prompting me to run the benchmark with libevent-2, this has been very interesting. I will think whether the added protection against fork is worth it (we still have the generation counter in libev for this case), and maybe make some similar change as explained before for libev-4.0. I am 70% convinced it can be done without sacrificing fork protection completely. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [email protected] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
