[Paul Davis] >>pipe()s here too. last time i benchmarked on an early 2.4 kernel, pipe >>and socketpair gave about the same timing figures, quicker than >>msgsnd/rcv. i don't remember the exact numbers but i remember being >>positively surprised. > >from the whitepapers that IBM did, the linux FIFO appears to be just >about the fastest IPC mechanism outside of a microkernel. i am not >sure if even futexes are actually significantly faster.
do you happen to have a pointer ready to those IBM whitepapers you mention? i've dug up the old benchmarking code today. it starts a RT thread that poll()s n times on a pipe, then pthread_cond_wait()s n times and finally msgrcv()s n times. the main thread writes the current gettimeofday() to a global and triggers the wakeup of the respective waiting mechanism, which compares the current gettimeofday() upon waking up. here are average numbers for 20 wakeups each: poll: avg 0.01705 ms cond: avg 0.01576 ms msg : avg 0.01045 ms this is on 2.4.22-ll, an 1.7 GHz athlon XP. the last time (referred to above in the OP) was on 2.4.5-ll (iirc) and a k6-III-450. so either they sped up msgsnd/rcv (which i doubt), my memory failed me (highly probable :) or there are significant differences in the respective kernel code path and processor flavour pairing (too esoteric to check). the conclusion i draw is that if you pthread_cond_wait now, you are probably better off switching to msgsnd/rcv if it fits into your scheme and you really want the speed. my personal opinion is that the ease of use of pipe and poll outweighs the microsecond-order gain msgsnd/rcv gives. it's still blazingly fast. ymmv of course. i can upload the benchmarking code if there's interest. >>giving you an fd, both pipe and socketpair can be operated on within a >>poll() loop, which is quite handy sometimes. don't know if futexes >>will do that? > >you can. it was added as an nth-round iteration of their >design. otherwise, it would be just another example of the crappy *nix >design where "waiting" is a different system call depending on what >you're waiting for. this sure is good news. though even if this weren't the case, i'm quite comfortable with poll, and i'd rather work with 'crappy *nix waiting' than ever MsgWaitForMultipleObjectsEx() another time in my life :) even if futexes will reach the speed msgsnd/rcv achieves, they'll have to make them a real breeze to use to make me dump the working FIFO code i am using now. tim
