Search code examples
c++csocketsmulticastpolling

Performance wise difference between poll with recv , epoll with recv and simple recv?


What is the Performance wise difference between poll with recv , epoll with recv and simple recv ? I have 4 multicast streams that i have to listen I think i have three options. i want to which is better n terms of speed , systems call , context switching.

1 poll with recv
2 epoll with recv
3 4 threads with recv

Please suggest me which is better and why


Solution

  • It will not matter much which of the three solutions you choose, the differences will not be huge. There is however one that will allow you to save syscalls (see at the end).

    For 4 descriptors, you can assume that poll is pretty much exactly as fast as epoll. This would be much different for 400 or 4,000 descriptors, but for 4 descriptors, poll is absolutely acceptable (though you can still use epoll of course, just don't expect a miracle). The important thing about epoll is how it scales in respect of the number of descriptors it watches, not so much how fast it is monitoring very few of them.

    Polling (with either function) and then receiving is obviously one more syscall than receiving directly in a thread, although depending on the exact nature of your problem, that may be a too naive way of looking at it.
    If the datagrams from these 4 multicast addresses can be processed independently, you can just fire up one process per port and block on recv (easiest solution!), but otherwise you need some kind of synchronization, which can be tricky to get right if you haven't done it before, and which may (will) involve extra syscalls or spinning and may quite possibly be slower than multiplexing receives.

    The number of context switches will roughly follow the number of syscalls whether you have threads or not (since you block in the syscalls most of the time anyway), unless you have a very busy machine with very few spare cores. In that case, throwing threads into the game will significantly increase the number of context switches.

    Multicast presumes UDP, which means "complete datagrams". Since you consider using epoll you have decided that portability is not an issue. You can therefore just as well use another Linux-specific syscall: recvmmsg. This allows you to receive several datagrams with only one syscall. If you had only one socket, you would just block on that, since it offers a "receive up to n" functionality. However, since you still need to multiplex 4 sockets, you will first use epoll and then recvmmsg.