Re: The revelation of St. f0dder the Divine

hutch wrote:
> Run a polling loop of the type above and the process takes so little
> processr time that it does not display any percentage of processor
> time. The real culprit is system idle that takes up about 93% of
> processor usage at idle and the other culprit is the system interrupts
> that take up 7% while the machine is just sitting there doing nothing.
> These percentages will vary depending on how much stuff your box runs
> at idle.

"Runs at idle"?

You say that as if it isn't an oxymoron...

If your machine is running stuff then it isn't "idle"...that's what
"idle" means, you see: The state of NOT doing anything...of _NOT_
"running stuff"...of _NOT_ being active...

So, by definition, you can't be "doing stuff" whilst "idle"...

And how can "system idle process" be a "culprit"? In what crime? The
idle process is _SUPPOSED_ to kick in when no other process is doing
anything...that's its purpose: The "catch-all" process...

And there's no need to worry about what "system idle process"
does...because the "idle" in its title is perhaps the big "give away":
It does _NOTHING_...by definition...that's the whole purpose of the
"system idle process"...

Indeed, this is where the CPU's "HLT" instruction is typically
used...and where there are other similar "power saving" measures for the
machine, then those are also typically triggered for the "system idle
process"...but, otherwise, the "system idle process" could be summed up
as:

----------------------------

Again: HLT
JMP Again

----------------------------

Yes, it sends the CPU to "sleep" (the reduced power non-executing state
that the "HLT" instruction triggers, anyway)...that's it...indeed, if
triggered out of the "HLT" sleep? Then it loops back around and sends
the CPU to sleep again...

And it does nothing else (except possibly sending other bits of hardware
to sleep with some "power saving" commands)...by nature, by definition,
by the whole darn fracking point of having a "system idle process": It
does NOTHING else...

While this might sound initially like an insane kind of process to want
to have running on your system - that does nothing but constantly send
the machine to "sleep" - the whole point is that this process is given
the system's _LOWEST_ priority...indeed, all other processes will have a
higher priority...

And, under a "priority" system, this means that if the machine has
ANYTHING - absolutely anything, no matter how small or big - to be
doing, then that process has a higher priority than "system idle" (by
definition: Nothing may have a lower priority than "system idle") and,
thus, it immediately "pre-empts" the "system idle process"...and starts
running...

Hence, the "system idle process" sends the machine to sleep (and that's
all it does in one big massive infinite loop :)...but this process only
ever executes when there really is absolutely nothing else at all for
the machine to be doing...so, when it well and truly is completely
"idle" - absolutely bugger all better to do be doing - this is the only
time the "system idle process" runs and what it does is, of course,
perfectly sensible and a good idea: It turns off the CPU with "HLT", in
order to give the CPU a break...saves power...allows the CPU to cool
down a little (remember, these things do run hot, after all)...stops
running instructions...

This is the whole point of this process...it is there to do
nothing...it's the process that makes the CPU sit back, relax, do
nothing, sunbathe, enjoy a relaxing massage and that kind of thing...the
"it's vacation time" process...

And it, by definition and design, should do absolutely nothing
else...bugger all...zip...

If you need the machine to do something - say, some "background scan" or
re-ordering memory or anything that might be usefully done when the
machine isn't doing anything better with its time - then you start a low
priority process...though, all processes have a higher priority than
"system idle"...

You've shown before that you don't entirely grasp how the "priority"
scheduling scheme in Windows works, hutch...and you're doing it again,
it seems...

Right, this is general OS theory, so it's not just Windows that follows
this scheme...but it's also applicable to most "multi-tasking" OSes that
you see out there...Linux, BeOS, the BSDs and so forth...

The system always has a "system idle process" running (its name may vary
from OS to OS, though, but it's always the same basic idea)...this
process is given the lowest possible priority in the system...indeed, if
the lowest priority a normal application can achieve is "1", then
"system idle" runs at "0"...by design and definition, "system idle" runs
at a lower priority than everything else...

And the basic, simple idea is this: Under the "priority based
scheduling" scheme, the scheduler always gives the highest priority
process (that isn't blocked: Actively demanding CPU time) the "first
stab" at the CPU...if a lower priority process is already running and a
higher priority process wants the CPU, then the lower priority process
is kicked off the CPU for the higher priority process...immediately...

Hence, if the machines has ANYTHING - no matter how small - to be doing
besides the "idle process", the "idle process" is kicked off the CPU and
the other process allowed to run (and that's why "system idle" process
must have the lowest priority in the entire system: Anything and
everything else - no matter how big or small - that requires CPU time
will always "pre-empt" the "system idle")...

As such, then as the word "idle" itself suggests, the machine has to
be - must be - doing NOTHING in order to enter the "system idle"...this
"process" isn't really a process, to be honest...it's the "catch-all"
for when there's absolutely no other process or anything for the machine
to be doing besides sitting "idle"...

So, it's not just the English language semantics of the word "idle" that
you can't be simultaneously "running stuff" and being "idle"...it's the
design of these priority-based scheduling schemes (that Windows, as well
as Linux and many others - most others - employ) that there is no
possible way to be "running stuff" and for the "system idle process" to
be on the CPU...

"System idle" can _ONLY_ be executing when there is NOTHING ELSE in the
system to be doing...this is "by definition"...this is the entire
purpose and design of the "system idle" process in the first place...it
cannot be any other way (and, if it were, then you've found yourself a
major "bug" in your OS)...

If you have some kind of "background scan" or other similar thing, then
it is simply "lower priority"...it's NOT "idle" priority (only "system
idle" can be "idle priority")...it runs at a lower priority to the other
processes and, so, those other processes always run first...but when
they aren't running, the lower priority process gets the CPU...

But the system is NOT "idle" at this point...the higher priority
processes are simply "blocked", to allow the lower priority through to
use the CPU...the system can be highly active at this point and it's
just the high priority process which has "blocked"...

[ You might be tempting to call this "the process has gone idle"...but
processes do not go "idle", the system goes "idle"...processes "block"
instead...this isn't solely a case of avoiding ambiguity to insist on
that terminology, it's logically sound too: The CPU can be anything but
"idle" when a particular higher priority process "yields" or "blocks"...

For example, I have a virus scanner that runs at a lower priority in the
background than all "normal" processes...now, say I was running some
program which does a series of calculations - "CPU bound" only - as a
"normal" process...this has the higher priority, so it "pre-empts" the
"background scan"...but there is NOTHING that means the higher priority
process is necessarily "doing more"...indeed, this high priority process
just does some simple calculations...the second it "blocks" or "yields",
though, it triggers a frenzy of activity in the "virus scanner": It's
spinning the disk around, reading files, comparing files to possibly
some pretty complicated heuristics and to its "database" of viruses,
etc., etc....it might be "low priority" but it's hardly an "idle"
activity...

"Priority" simply refers to its importance in getting the CPU
first...raising process priority is something many people think might
"speed up" a process...in fact, in certain situations, you could
actually be drastically slowing it down...if you give "real time"
priority to the wrong process - one that's gone AWOL - then you, in
fact, would totally lock up the entire system (your only escape being
the big "reset" switch on the front panel of the PC ;)..."priority" also
has NOTHING to do with how "active" a process is...being "lower
priority" does NOT mean that this process "does less" than other
processes...indeed, the obvious example of a virus scanner's "background
scan" is the classic example because, there, it might be running "low
priority" in the background but running a "virus scan" on all your files
on all your hard drives, checking against a large database and
"heuristics" and so forth? This is perhaps _THE_ most "frenzy of
activity" process that the system ever runs (except maybe defragmenting
the drive or something like that)...on the contrary, this "background
scan" is among the "most active" things the system ever does...

In fact, this example demonstrates that it's very possible that it works
the other way around...if, hypothetically, the "virus scan" could be run
within 10 seconds to check every file on all the hard drives in the
blink of an eye, then it wouldn't be a "background scan" at all...you'd
load it up, hit "scan", wait 10 seconds and then, if all is well, carry
on with what you were doing...

It's the very fact that "virus scanning" is a highly involved and
long-running process that mandates that these "scans" have to be
performed as "background scans"...because if you loaded it up, hit
"scan" and had to wait 3 hours before you could do anything else, then
everyone would "avoid" running the virus scanner because all it does is
"get in the way" and stop them getting to do "useful work"...by putting
it "low priority" as a "background scan", this ensures that it does get
done (more slowly, if there's a lot of other activity going on in the
foreground) because it can proceed without requiring the user to "wait"
before using other applications and such...therefore, the fact that a
process is "highly active" can actually lead to it having it "priority"
dropped, so as not to disturb everything else the user also wants to do
simultaneously... ]

Also, what specification machine are you running there? Because I'm very
surprised to see only "93%" for "system idle", if the machine truly is
completely "idle" and doing nothing else...and "7%" for system
interrupts seems a little "steep" too...

What this actually "depends on" more than anything, though, is your
system's speed...these are "percentages", after all...and the code
Windows runs is the same regardless of CPU speed (and the scheduler is
hooked up to _real world_ time, which - Einstein to one side and
thinking Newton because it's unlikely the PC is being fired at "near
light speed" from a cannon at the time of measurement - is the same for
all machines :)...so, yes, if the system is "less capable" then the
figure used up on "system interrupts" could be higher than for a more
capable and faster running system...

Though, for anything released this century (or even five years before
the turn), I'd still be suspicious to see "system idle" only getting
93%, when the system is in a truly "idle" situation...are you sure
you're reading your dials and meters correctly there?

Although, if it is devoting 7% of system resources simply to "system
interrupts" then you help demonstrate your Microsoft friends'
"bloatware" incompetence, as 7% of system resources just for "ticking
over" the machine is pretty dreadful efficiency, really...


But, again, as was the case with the argument between you and f0dder
before, hutch, the essential problem here is that you seem unable to
recognise that "polling" and "blocking" are fundamentally _DIFFERENT_
operations...it isn't only a case of which "runs fastest"...or which
takes up the most CPU time...

[ Though, as "blocking" actually literally deactivates a process from
getting any CPU time whatsoever, then it's a rare situation where that
doesn't prove the "superior", seeing as we're touching on that
subject...basically, only when the "overhead" of instituting the
"blocking" scheme ends up greater than just doing the
"polling"...indeed, when the process is being "blocked / unblocked /
blocked / unblocked" with such alarming frequency that it's really
almost "polling", it's getting the CPU so often...and, well, effectively
"polling" but also taking in the "blocking overhead"? You'd be better
off literally "polling"...

Not that, at this point, I want to bring up the point about X's superior
"event mask" model...and the incompetently pathetic ommission in Windows
by Microsoft of a similar approach - with its "machine gun message"
model - which marks Windows out as a "toy" Microsoft put together just
to make money, NOT a serious and well-designed system whatsoever...no, I
wouldn't want to point that out at this juncture because that wouldn't
be fair on poor little Microsoft... ]

They are fundamentally different approaches...they are, if you like,
solutions for _different_ kinds of problems...it isn't that one "runs
faster" or "runs slower" than the other...it's that they run _DIFFERENT_
from each other...

So, yeah, sure...no-one, I think, was expecting the "polling" version to
necessarily chew up all the CPU time...that's NOT the issue...the issue
is whether this is the correct approach...

Indeed, if your "polling loop" there is NOT taking up all of the CPU's
time, then what are the _REASONS_ behind this? That's
important...because, strictly, if it's "polling" then it should be
taking up the CPU time completely...the fact that it isn't, doesn't mean
you're now "let off the hook", it means we need to understand exactly
_WHY_ it isn't taking up all the CPU time, as, really, it should be...

The other comments mean you couldn't have lowered its priority...as
"system idle" is running, according to your figures...so, this is the
only thing you're running...and, basically, when there's only one
process running, "priority" is immaterial..."system idle" is always
going to be "lower priority" and your process has no actual
"competition" for the CPU at all ("system idle" never "competes" with
any process to get CPU time: It only gets it when all other processes
have no need of the CPU)...

So, if your application demanded all of the CPU time, then it would _GET
IT_ (the "system overhead" excluded, of course, as you can't not have
that running for obvious reasons)...

Hence, if your "polling loop" above is taking up "neglible" CPU time
when executing, there's got to be a reason for this...

And that reason, I would hazard a guess, is that your "polling loop", in
fact, isn't a "polling loop" at all...

Oh, sure, you _THINK_ it's a "polling loop" but you're wrong about
that...it cannot be...or it would, in fact, be taking up all the
available CPU time (and, as you're running nothing else - the "system
idle" figures demonstrate that this is the case - then that translates
as "all the CPU time"...period)...

Hence, the very fact that it isn't taking up all the CPU time is proof
that the supposed "polling loop" isn't actually a "polling loop" at
all...that you've NOT accounted for the fact that though you may be
using the API in a "polling" capacity, the OS API themselves are not
necessarily also using "polling" under the hood...indeed, you can bet
your bottom dollar that the OS API tend to "blocking" whenever they can
(as, under a priority-based scheduling scheme, this is typically the
"superior" method to follow overall)...

So, your "polling loop" isn't, in fact, "polling" at all...at least, it
might be "polling" from a high-level abstract perspective of your own
code (and only your own code)...but the code inside the OS API must be
using a non-polling scheme for your program not to be taking up all of
the CPU's time completely...

Which brings us back to the original point: As this is the case, then
why are you fighting against the grain of the OS itself?

Don't worry...your postings on this matter have made perfectly clear
what the answer to that is: You don't really know how pre-emptive
scheduling in your OS actually works...this is yet another time when
you've call something a "polling loop" when that isn't really what
you've got there at all...and you keep using "polling" rather than using
"blocking" API...which, by and large, totally goes "against the grain"
and the operation of the OS API you're using...

It would be in your interest, hutch, to go and find out how pre-emptive
priority-based scheduling actually works...as your repeated comments in
this area, sorry, display that you don't know the subject as well as you
should...and you might not continually pick the least efficient method
for your programs all the time, trying to "fight" the OS's own "grain"
all the time...

You're not a stupid person...if you dropped the "ego" for five minutes
and actually read up on it, then I know perfectly well that you'd
comprehend it all first time...no problems, mate...which, of course,
just makes your insistance to "blag" your way through talking about it
all the more absurd to watch...look, just read up on the subject...it
won't take you long...you're sure to immediately comprehend it - it's
not difficult or anything - and, from then on, you'll stop making silly
comments...your programs will be a little more efficient (yes, your
program takes up less than 1% of CPU time that it doesn't show on the
"meter"...but with a "blocking" version, your program really _IS_ taking
"0%" - absolutely no CPU time at all - and it's not just a "rounding
error" optical illusion)...

Plus, you tend to only think of your program...but when dealing with
"scheduling", you have to think of the whole system...for example, when
you had that program which "polled" but you thought it "okay" because
you'd dropped its priority...and that's "much the same thing", right?
Actually, no, you're wrong...it isn't...

As I've stressed above, the two approaches are not "two equivalent ways
to skin a cat"...there are fundamental differences between them...for
example, you've dropped the priority and then "poll" instead...reasoning
that if the priority is lower then it's not going to get in the way of
other programs running, so it's an "okay" approach...

But, sorry, you have to be more careful and smarter when it comes to
"scheduling"...it's too darn easy to create a program that brings about
"starvation" of one kind or another...for example, you drop the priority
and "poll"? Okay, I start running a program - "normal" priority - that
does a lot of heavy processing and doesn't "block" or "yield" very
often...in fact, I decide to start 10 of these programs...and - BANG! -
your "lower priority" process is now "starved" of any CPU time at
all...higher priority processes always get the CPU first and there's
enough of them running that, basically, your "lower priority" process
now effectively never runs at all...it's "polling" looking for the "exit
code" of a child process? Fine...then the child process terminates...but
the "polling" program - constantly usurped from CPU time by the many
"normal priority" programs running - doesn't ever get to realise that
this has happened because it's never given CPU time to check?

[ Indeed, most OSes "cheat"...they include "anti-starvation" techniques
where it basically, every once in a while, violates its own "priority"
rules to let a lower priority process run above a higher priority
process...but rarely and infrequently...just a small "cheat" to avoid
these "totally locked out of getting any CPU time at all" starvation
situations, where a bad design - like you insist upon - could
accidentally create a "deadlock" / "livelock" set of
conditions...arguably, though, OSes really shouldn't be tolerating bad
designs like this, as it doesn't help educate the programmer to do it
correctly in future...and some OSes might not be as "kind" and implement
things highly rigidly...if you "ported" the code to such an OS, then
you'd suddenly be dumbfounded and at a loss why, all of a sudden, the
program which worked fine on one system, suddenly won't ever complete on
another system... ]

Concurrency is _NOT_ a simple issue...it exponentially increases the
complexity of the considerations needed to do the job properly...the OS
does its best to "shield" you from too much complexity, so that you can
concentrate on your own program...but when dealing with issues that
involve multiple processes (waiting for "exit codes" and such), you
cannot continue to operate inside the "convenient abstraction" that
yours is the only program running in the entire system...

As mentioned, with the "lower the priority and poll" method you were
using before, then it's possible for me to carefully select _OTHER
PROGRAMS_ to run alongside your program which "starve" it and, thus,
fail to allow it to terminate...and, like it or not, such potential
situations _ARE_ your concern when you start getting "concurrent" about
things...

Concurrency _CAN_ produce "non-deterministic" results...I know...you
were taught that machines are completely "deterministic" - run a program
a hundred times and you'll "always" get the same result at the end - but
this is the simplified "sequential" viewpoint...it actually is NOT true
of individual processes running in a concurrent system, unless they are
written correctly...

Beth :)



.