hyper threading.

[Anthony Atkielski]

em1897 at aol.com writes:

> Things have changed a bit since then, so I doubt that
> "proof" has any relevance.

The principles haven't changed at all.

Servicing interrupts is an extremely high-overhead activity.  There's a
minimum amount of time it takes, no matter how short the interrupt
routine.  There comes a point when just the inherent cost of the context
switch is responsible for most of the overall cost of the interrupt
service, and with a large number of interrupts, the processor(s) can
spend a great deal of time just switching contexts.

Polling eliminates this overhead by simply checking for I/O to service
when it is convenient for the OS.  As long as polls occur frequently
enough not to miss any pending I/O, it's faster than interrupt-driven
I/O.  The total number of instructions executed is often greater,
because the OS tends to spin on its polling tasks, but the absolute time
required to respond to a given I/O event can be much shorter.

In my case, I divided all the work of the comm program into small bits
that could be done in tiny chunks.  Each time a chunk was completed, I
polled the serial port.  Since chunks never exceeded a certain size, I
always managed to poll the port in less time than it took to receive a
character, even at 38,400 bps.  The system was busier than it would be
with interrupts driving it, but it responded more quickly to incoming
traffic, and there were no transfer timeouts, whereas with interrupts,
the system was less busy, but it timed out very consistently at high
communications rates.  By using more processor but evening out the use
of processor so that it was more consistently distributed, very high
communication rates could be handled by the program.

All of this remains permanently applicable today, and it is why some
high-speed applications poll instead of waiting for interrupts.

-- 
Anthony