18 Jun
2004
18 Jun
'04
9:04 a.m.
[Paul Davis]
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.
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
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. 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.