Improved polling benchmarks (fwd)

[Dean Gaudet <dg...@arctic.org>]

Just in case anyone else finds this interesting ...

Richard's proposed poll2() is essentially the same as poll() except it has
an infds and an outfds, and when a fd has an event it is copied into the
outfds ... so that you don't have to scan the entire input set just to
find a couple output events. 

Dean

P.S. I've considered using poll() in Apache ... because slacking can move
the network sockets to high numbered descriptors and select() is
inefficient up there. 

---------- Forwarded message ----------
Date: Sun, 31 Aug 1997 18:39:39 +1000
From: Richard Gooch <rg...@atnf.CSIRO.AU>
To: linux-kernel@vger.rutgers.edu
Subject: Improved polling benchmarks

  Hi, all. I have updated my polling benchmark programmes and placed
them on my ftp site at:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/benchmark-code/

The updated code also includes the time taken for minimal processing
of data returned by the kernel. I've done some timings on a few
different platforms. All timings are for polling for activity on file
descriptors created by a rlogin session.
-------------
Here are the timings for a Pentium 100 running Linux 2.1.51 with the
various patches I've recently submitted:

Test 1: checking descriptors 24-1023, activity on 1014-1023:
select: 619 microseconds
poll:   893 microseconds
poll2:  681 microseconds

Test 2: checking descriptors 524-1023, activity on 1014-1023:
select: 472 microseconds
poll:   379 microseconds
poll2:  301 microseconds

Test 3: checking descriptors 824-1023, activity on 1014-1023:
select: 387 microseconds
poll:   154 microseconds
poll2:  124 microseconds

Test 4: checking descriptors 924-1023, activity on 1014-1023:
select: 360 microseconds
poll:   98  microseconds
poll2:  73  microseconds

The current interface to poll2(2) is:
struct poll2ifd
{
    int fd;
    short events;
};
struct poll2ofd
{
    int fd;
    short revents;
};
extern int poll2 (struct poll2ifd *ifds, struct poll2ofd *ofds,
		  unsigned int nfds, int timeout);

For those who have been following this thread, the reason that the
passing of user pointers has been discarded is that I feel it is not
absolutely essential. The file descriptor itself can be used as an
index into an application-specific array of structures. Removing the
passing of user pointers will slightly reduce the memory footprint.

I think these tests show that, except where you are polling all or
most file descriptors up to your maximum file descriptor, that poll(2)
and poll2(2) have a significant advantage over select(2). Where you
are polling most fds up to max_fd, then select(2) wins out heavily
against poll(2) but only marginally against poll2(2).
A simple example of why you would only poll a portion of your
allocated fds is if you have a threaded server: each thread polls a
block of fds. In this case using select(2) would be a loose. You would
be much better off with poll(2).

The rationale for poll2(2) is that it has the advantages of poll(2)
(and more) but in the worst case it is not too much slower than
select(2). It is able to give best all-round performance with a single
interface.

-------------
Here are the timings for a HyperSPARC 90 running Solaris 2.5:

Test 1: checking descriptors 24-1023, activity on 1014-1023:
select: 2496 microseconds
poll:   1961 microseconds

Test 2: checking descriptors 524-1023, activity on 1014-1023:
select: 1276 microseconds
poll:   983 microseconds

Test 3: checking descriptors 824-1023, activity on 1014-1023:
select: 555 microseconds
poll:   405 microseconds

Test 4: checking descriptors 924-1023, activity on 1014-1023:
select: 319 microseconds
poll:   217 microseconds
-------------
Here are the timings for a r8000 75MHz running IRIX 6.2:

Test 1: checking descriptors 24-1023, activity on 1014-1023:
select: 69483 microseconds
poll:   69248 microseconds

Test 2: checking descriptors 524-1023, activity on 1014-1023:
select: 14918 microseconds
poll:   14734 microseconds

Test 3: checking descriptors 824-1023, activity on 1014-1023:
select: 4536 microseconds
poll:   4470 microseconds

Test 4: checking descriptors 924-1023, activity on 1014-1023:
select: 2078 microseconds
poll:   1993 microseconds

It's quite gratifying to see that Linux does so well in comparison. I
must say I'm rather surprised at the extremely poor performance of
IRIX: I would have thought that SGI would have spent some time
optimising polling, since these days they seem to be targetting the
high-end WWW server market.

				Regards,

					Richard....