Re: Timings for optimised poll(2)

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Mon, 25 Aug 1997 07:53:38 +0200 (MET DST)


Dean Gaudet wrote:
>
> On 25 Aug 1997, Michael O'Reilly wrote:
>
> > This is one of the reasons you use select(). It means you can scan a
> > bit array very fast.
>
> and the kernel scans a normal array really slow underneath. Somewhere
> someone pays the costs in the select and poll models.
>
> select() is O(n) where n is the max descriptor. poll() is O(m) where m is

No:

1) m = O(n) in the cases that we are interested in.
2) The kernel builds a list of the selected-on fd's and indeed needs to
poll the whole list to get the set of ready descriptors.

> the number of descriptors. Both are linear in their inputs ... m <= n...
> poll is generally more efficient at the kernel level since select is
> implemented in terms of poll. Even in the cases where the outputs are
> sparse and find_first_zero_bit becomes a win, you still had to pay for
> O(n) operations inside select(). So timing things at the user level only
> is totally bogus.

My timing example shows that you can totally obliterate the "extra
overhead" That Richard claims exists for using "select". He wrote some
code that is 10000 times slower than mine, and then starts shouting
that we need a different kernel-interface.

Roger.