2012-02-10 20 views
11

¿Alguien tiene alguna idea del rendimiento relativo de GAsyncQueue de GLib frente a la cola de mensajes POSIX para la comunicación entre hilos? Tendré muchos mensajes pequeños (tanto de ida como de solicitud y respuesta), que se implementarán en C en la parte superior de Linux (por ahora, pueden transferirse a Windows más adelante). Estoy tratando de decidir cuál usar.GLib's GAsyncQueue vs. POSIX message_queue

Lo que he descubierto es que usar GLib es mejor para la portabilidad, pero POSIX mq tiene la ventaja de poder seleccionar o sondear en ellos.

Sin embargo, no he encontrado ninguna información sobre qué rendimiento es mejor.

Respuesta

14

Como no hubo respuestas a mi pregunta, decidí realizar algunas pruebas de rendimiento. La idea principal fue tomada desde http://cybertiggyr.com/throughput/throughput.html. La idea de prueba fue:

  • Crear dos hilos (pthreads/gthreads).
  • Un hilo produjo datos y escribió al IPC en fragmentos hasta que se enviaron 1024 MB de datos.
  • El otro hilo consumió datos del IPC. He probado con tamaños de fragmentos de 4, 64, 256, 512 y 1024 bytes. Probé con GAsyncQueue (con gthreads), cola de mensajes POSIX y sockets de dominio UNIX (con pthreads).

Aquí es el resultado obtenido:

enter image description here

Para resumir, perf (GAsyncQueue)> perf (mq)> perf (socket UNIX), aunque las actuaciones de GAsyncQueue y POSIX cola de mensajes son comparable en la mayoría de los casos: la diferencia ocurre solo con tamaños de mensaje pequeños.

Me preguntaba cómo se implementa GAsyncQueue para ofrecer un rendimiento comparable incluso mejor que la implementación de la cola de mensajes nativos de Linux. Es una pena que no se pueda usar para la comunicación entre procesos, como las otras dos.

+1

Muy interesante. He votado su respuesta y pregunta, tal vez ahora le permita publicar los gráficos. – kalev

+0

Realicé algunos experimentos más: agregué señalización entre hilos para informar al consumidor que se han producido datos. Usé la técnica eventfd Linux. Y tan pronto como lo hice, vi que el rendimiento de GAsyncQueue degradar era similar a los demás. – dbikash

+1

¿Esto da una explicación de los resultados? Que todos los mecanismos de IPC de Linux pasan por el núcleo y, por lo tanto, tienen un rendimiento similar. GAsyncQueue de alguna manera tiene una implementación de espacio de usuario - espacio de usuario adicional - se evita la copia de espacio del kernel, lo que resulta en un mejor rendimiento. Y tan pronto como se agrega el mecanismo eventfd, nuevamente el núcleo entra en la imagen. Es ese entendimiento correcto? – dbikash