Sockets - Select vs epoll

Je me suis livré à une petite comparaison de la latence de diverses solutions pour écouter sur une liste de sockets. Mon programme de test contient un thread qui mitraille l'interface de loopback avec de petits messages UDP broadcast contenant un timestamp (obtenu avec clock_gettime sur CLOCK_REALTIME, et surtout pas sur CLOCK_PROCESS_CPUTIME_ID qui peut renvoyer des résultats inconsistants depuis des threads différents).

Un autre thread va écouter sur la même interface, décoder le message, et afficher la différence de temps entre le timestamp reçu et l'heure courante.

Cet autre thread est implémenté soit en utilisant la bibliothèque Asio de chez boost, soit un appel à select, soit un epoll. Cet autre thread, en plus d'écouter sur l'interface, va également écouter d'autres sockets qui ne reçoivent rien. L'on a ainsi un socket très occupé, et les autres qui attendent sagement. Voici donc les résultats de latence (en microsecondes) en fonction du nombre de sockets:



Lorsque l'on écoute sur un seul socket, select est le plus rapide, suivi par epoll et asio, bon dernier. Par contre, lorsque l'on veut écouter sur plus d'un socket à la fois, select ne scale pas bien du tout! La raison est que select va regarder tous les descripteurs de fichier entre 0 et le plus élevé de l'appel, et flagger ceux que l'on veut suivre. Epoll (et Asio, qui est basé sur epoll) reposent sur des mécanismes plus évolués, qui permettent de garder une complexité constante au fur et à mesure que le nombre de descripteurs augmente.