Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions

From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 02:39:06 GMT

"Frank Kotler" <fbkotler@comcast.net> wrote in message
news:40F56D02.6AFC8F4@comcast.net...
> Randall Hyde wrote:
>
> I won't dispute your expertise on "what name things are called by", but
> ISTM that if these two vastly different situations are called by the
> same name, the terminology is less useful than it might be. Hutch has
> suggested "Bethpolling" - I think "pure-polling" and "blocking-polling"
> might be more descriptive...

Why not? After all, "cooperative multitasking" seems to have replaced
"multiprogramming" in the lexicon. Look at all the people around here
using Rene's "Preparser" term even though the correct term is really
"pre-processor". Go for it, I say!

>
> It's true that "blocking-polling" wastes some cycles on uninteresting
> messages, but it's only "one iteration's worth" per message.

The definition of polling never really considered how much time actually
was wasted. After all, one place where polling is quite valuable is when
the data is coming in so fast that the interrupt handling latencies can be
a problem. In such cases, you spend very little time in the polling loop.
But it's still polling.

> A
> "pure-polling" loop (like "Hutch's loop", or a messageloop that did
> "call PeekMessage/cmp eax, NO_MESSAGE_AVAILABLE/ jz top" continually)
> would waste *far* more cycles. (This assumes that a message is *not*
> available "most of the time" - is this untrue?) From the viewpoint of
> the application, there isn't much difference, but to another task that
> could be using the CPU time given up by "blocking-polling", it's a *big*
> difference! (the exact difference would depend on the
> available:unavailable ratio and on the interesting:uninteresting ratio,
> I suppose...)

I cannot comment on Hutch's approach. I have no idea how much
time it wastes or doesn't waste. I do know that most attempts to
optimize the Windows message loop are a complete waste of time
(someone posted some really tricky code here a while back, where
they *carefully* optimized the Windows message loop. I measured
it with RDTSC and found that they saved a whooping 100 cycles
out of the 80,000 or so that executed between each loop. Not
a great example of optimization...)

>
> This feels really weird to me. I'm almost tempted to accuse you of
> "thinking like an old dos-head" - and that's supposed to be *my* role!
> :)

I'm thinking like an instructor who would be marking lots of points off
on a midterm exam for people trying to B.S. their way through the test :-)

>
> In any case, this discussion prompts a philosophical question for the
> LuxAsm team... If it were possible to speed up LuxAsm by being
> "inconsiderate" and hogging resources, would this be an acceptable
> method of speeding up LuxAsm? (I suppose the answer depends on "how
> much?"...)

Of course not. That's for the user to do. If they want Luxasm to run
faster, they need to bump the priority up, that's all.
Cheers,
Randy Hyde

Relevant Pages

  • Hutch, give it up.
    ... > I confess to being surprised at the more recent antics of Randall Hyde ... Actually, there are lots of "true" ways, but polling isn't one of them ... > backround in academia is the details of analysis failure when it comes ... > if the assertion is either true of false. ...
    (alt.lang.asm)
  • Re: Why RosAsm Breaks on a large number of symbols
    ... > polling loop and all you have to do to prove this is trap a keystroke ... > in the polling loop, either manually or with one of the standard API ... message loop is classified as a Message Receiving loop. ... A Windows message loop can ...
    (alt.lang.asm)
  • Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions
    ... Randall Hyde wrote: ... >> The classic polling loop has been all but relegated to relic status. ... process while the I/O completes. ...
    (alt.lang.asm)