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

Question

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

if you know that you will never ever ever handle any other stream count than 4 go with 4 threads, that should be sufficient and much more easier to implement. However if you will need to scale then go with epoll. — Rudolfs Bundulis, Oct 30 '14 at 12:41
possible duplicate of [Whats the difference between epoll, poll, threadpool?](http://stackoverflow.com/questions/4093185/whats-the-difference-between-epoll-poll-threadpool) — deW1, Oct 30 '14 at 12:42
@deW1 i already go through that answer but didnt find answer for my specific problem. — Rsvay, Oct 30 '14 at 12:45
@RudolfsBundulis thanks for the answer what i am thinking if i use poll with recv or epoll with recv i have to make two system calls but in case of thread i have to make only one system call. i think simple recv will be fast do u agree. — Rsvay, Oct 30 '14 at 12:50
@MartinJames in terms of speed , systems call , context switching — Rsvay, Oct 30 '14 at 12:56
@user2617519 well if you have a dedicated thread for each stream you don't have to do any work dispatching on a pool of worker threads that you would have to do in case of poll and epoll if the work is cpu bound. It all depends on what you will do with the content. If you are going to for example decode it and that can be done in an asynchronous way then poll/epoll is also a fine choice. In case of 4 threads the context switching is not a serious problem. — Rudolfs Bundulis, Oct 30 '14 at 13:05

score 3 · Accepted Answer · answered Oct 30 '14 at 13:32

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.

thanks for your help and time. I am also not expecting huge difference but if difference is in micros its very huge for my specific problem and also synchronization is not a problem as all 4 multicast stream generated from the same source and source generate one packet every 35 microse to 1 of 4 streams. — Rsvay, Oct 31 '14 at 05:59
finally i implement both recv with thread and epole then compared them and the result is recv with threads is around 2 micro sec faster then recv with epoll. thanks for your help — Rsvay, Oct 31 '14 at 09:05

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

1 Answers1