Date   : Sat, 14 Aug 2010 23:38:19 +0100
From   : tom@... (Tom Seddon)
Subject: Windows-friendlier 65Link server

On Sat, 14 Aug 2010 01:29:53 +0200, "Rick Murray" <rick@...>
wrote:

>On 14/08/2010 01:18, Tom Seddon wrote:
>
>> The server supplied in the standard Windows distribution uses up all
>> the CPU time it can get, and Windows's shady multitasking means that ?
>> particularly on a single-core machine ? the computer is unusable for
>> anything else as a result.
>
>Mmm, I had that with one of my programs. Sort-of fixed it by dropping in 
>a few calls to sleep() at relevant times. The program now runs like 1% 
>slower but the computer runs 100000% faster.

I think that sleeping is the correct solution. Windows does do
preemptive multitasking, but it's pretty polite about it. And even
processes that call blocking functions (which put the thread to sleep
while the function runs) get a priority boost once they wake up due to
the call's completion. So if a program goes into a tight loop, either
doing CPU work or calling blocking functions that are likely to
complete quickly, it will end up eating more than its "fair" share of
CPU time. Either Windows keeps boosting its priority a bit, or it is
gentle about putting it in the background in the first place.

I put "fair" in quotes delibately, because if something is doing work,
surely it deserves the CPU more than anything else? (Rhetorical
question, but Windows seems to say "yes".) So if your program is going
to use the CPU, but you don't want it to use the CPU as much as it
looks like it should, you need to give Windows some kind of hint.
So... sleep.

Windows's approach is obviously suboptimal, because it sometimes
doesn't work so well. When I was using Linux, though, I was never very
happy with the UI response, even if (in contrast to Windows) it was no
worse when running a compile in the background. So I guess if you do
it properly, that sometimes doesn't work well either!

I suppose Windows could do with some kind of UI for tweaking the
scheduling behaviour for particular processes, but I'm not holding my
breath. I suspect the mind-reading PC will arrive first. That would
help with Linux, too.

> And, I might point out, 
>that this is XP with the process running as "normal" priority. I might 
>also point out that whatever process priority I set my XviD encoder at, 
>it runs the same speed. Go figure.

Interesting... though if you're just watching the dialog, that might
explain it. If a high priority process will get 99% of an idle CPU, an
idle priority process might get... 97%? 98%? Is it as good if you
compile something at the same time? :)

--Tom