[LAD] Pipes vs. Message Queues

David Robillard d at drobilla.net
Sat Nov 26 00:00:25 UTC 2011

On Fri, 2011-11-25 at 15:21 +0100, Nick Copeland wrote:
> So if the pipe() is replaced with 
>     socketpair(PF_UNIX, SOCK_STREAM, PF_UNSPEC, pipe_fd);
> Then the issue I was seeing goes away. Perhaps the pipe() code has not been 
> optimised since sockets were developed to replace them when IPC suddenly 
> needed to be between hosts rather than processes? Pure conjecture.

Added sockets:

Normal scheduling:

$ ./ipc 4096 1000000
Sending a 4096 byte message 1000000 times.
Pipe recv time:  7.048740
Pipe send time:  7.048648
Socket send time:  2.365210
Socket recv time:  2.365292
Queue recv time: 2.072530
Queue send time: 2.072494


$ ./ipc 4096 1000000
Sending a 4096 byte message 1000000 times.
Pipe send time:  5.279210
Pipe recv time:  5.279508
Socket send time:  2.709628
Socket recv time:  2.709645
Queue send time: 5.228892
Queue recv time: 5.228980

Interesting.  I find sockets being significantly faster than the much
simpler pipes quite counter-intuitive.

Code at the same location:


What would be a more interesting/relevant benchmark is to spawn p
processes, and have each send a message to the next in a chain.  Measure
the time from the start until the very last process has received the
message.  That should give us a pretty good idea about the sort of
scheduling behaviour we actually care about, and you can crank up p to
make the difference very apparent.

Science is fun.


More information about the Linux-audio-dev mailing list