I got curious, so I bashed out a quick program to benchmark pipes vs POSIX message queues. It just pumps a bunch of messages through the pipe/queue in a tight loop. The results were interesting:
$ ./ipc 4096 1000000 Sending a 4096 byte message 1000000 times. Pipe recv time: 6.881104 Pipe send time: 6.880998 Queue send time: 1.938512 Queue recv time: 1.938581 Whoah. Which made me wonder what happens with realtime priority (SCHED_FIFO priority 90): $ ./ipc 4096 1000000 Sending a 4096 byte message 1000000 times. Pipe send time: 5.195232 Pipe recv time: 5.195475 Queue send time: 5.224862 Queue recv time: 5.224987 Pipes get a bit faster, and POSIX message queues get dramatically slower. Interesting. I am opening the queues as blocking here, and both sender and receiver are at the same priority, and aggressively pumping the queue as fast as they can, so there is a lot of competition and this is not an especially good model of any reality we care about, but it's interesting nonetheless. The first result really has me thinking how much Jack would benefit from using message queues instead of pipes and sockets. It looks like there's definitely potential here... I might try to write a more scientific benchmark that better emulates the case Jack would care about and measures wakeup latency, unless somebody beats me to it. That test could have the shm + wakeup pattern Jack actually uses and benchmark it vs. actually firing buffer payload over message queues... But I should be doing more pragmatic things, so here's this for now :) Program is here: http://drobilla.net/files/ipc.c Cheers, -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
