News for hackers. Stuff that matters.
Re:LibPhenom, a high-performance C eventing framework from F... by astrodust on Monday September 16, 2013 @03:40PM (#6395381)
Does anyone know how this compares to the standard libevent or the quirky allegedly faster libev (http://software.schmorp.de/pkg/libev.html)?
Re:LibPhenom, a high-performance C eventing framework from F... by wezfurlong on Monday September 16, 2013 @04:47PM (#6395801)
We're a bit faster than libevent in terms of dispatch throughput; some benchmarks in this commit message: https://github.com/facebook/libphenom/commit/41b6106f04fe62c...

The `tests/bench/iopipes.t` "test" allows you to play with some concurrency parameters to try this for yourself on your hardware.

We haven't compared against libev.

We've added some more APIs (buffers and sockets) since those benchmarks were done and we don't have numbers to share around those yet.

One key difference between libevent, libev and libuv is that libphenom is inherently multithreaded in its IO dispatcher and timeout implementation.

If you're dispatching purely CPU bound jobs, we get very close to linear scaling with the number of cores: https://github.com/facebook/libphenom/commit/c2753c2154a0cff...

Re:LibPhenom, a high-performance C eventing framework from F... by mrb on Tuesday September 17, 2013 @12:24AM (#6397551)
What do you mean by "inherently multithreaded"? I have written a network application handling 100-500k TCP concurrent connections using libev. It was multithreaded to distribute the number of connections evenly per thread (typically from 10k to 100k connections per thread). This is a model that is perfectly supported by libev. And I observed a nice linear scaling of the network throughput with the number of cores since my jobs were also purely CPU-bound. Depending on how CPU intensive my jobs were exactly, my libev code needed anywhere from 2 to 10 threads to saturate a GbE link.
Re:LibPhenom, a high-performance C eventing framework from F... by wezfurlong on Tuesday September 17, 2013 @01:32AM (#6397763)
The principal difference between the libphenom event dispatcher and the other event libraries is that libphenom can wakeup and dispatch IO events to any of the IO scheduling threads (no thread affinity).

Contrast with the libevent approach of using an application specific scheme to assign descriptors to an event base associated with a thread (strong thread affinity).

This makes more of a difference if you have chatty protocols and/or long lived sessions and no way to rebalance your fd -> event_base mapping.

Re:LibPhenom, a high-performance C eventing framework from F... by kev009 on Monday September 16, 2013 @04:36PM (#6395721)
There's a lot more framework in place for building an application here... hash tables, configuration files, JSON, performance counters.

libevent/libev are easier to retrofit into existing applications. This looks like something you'd start a new application with. libuv is somewhere in the middle.

Re:LibPhenom, a high-performance C eventing framework from F... by petsos on Monday September 16, 2013 @08:22PM (#6396817)
Exactly, I think it is more relevant to compare to e.g. glib.
Re:LibPhenom, a high-performance C eventing framework from F... by escaped_hn on Monday September 16, 2013 @05:18PM (#6395977)
what about libuv?
Re:LibPhenom, a high-performance C eventing framework from F... by otterley on Monday September 16, 2013 @06:07PM (#6396227)
... and libev?