Re: Timings for optimised poll(2)

Michael O'Reilly (michael@metal.iinet.net.au)
25 Aug 1997 09:12:49 +0800

Richard Gooch <rgooch@atnf.CSIRO.AU> writes:
>
> There are a few reasons why you would not use the find_first_zero_bit
> function in a real-world application:
>
> 1) it assumes you are using select(2) and fd_sets. This has the old
> problem of hard-wired limits on the fd_set size. Today the limit is
> 1024. Tomorrow somebody wants more, so you have to recompile your
> kernel. If you want to manage a large number of descriptors, you would
> use poll(2) instead

No, you only recompile your application. The kernel get passed the
number of bits in the set. If you've hard coded limits into the
kernel, that's a seperate issue.

> 2) every time poll(2) or select(2) returns, you may get dozens of
> descriptors which are ready. How do you solve this? Call
> find_first_zero_bit for each active descriptor (clearing as you go)?

Why not? It's still a hell of a lot faster than the silly code you
have below. The vast majority of the time, only a handfull of the bits
are going to be set.

> I've appended my latest version test programme. Compile with -O2. This
> contains a *realistic* scanning loop. It takes 1.5 milliseconds on a
> Pentium 100.

Congratulations. You managed to time a naive scan through a large
array.

This is one of the reasons you use select(). It means you can scan a
bit array very fast.