Re: Wiseman and McGhie are Ranting Again

In article <BF535780.1F8E8%john@xxxxxxxxxxx>, John McGhie [MVP - Word
and Word Macintosh] <john@xxxxxxxxxxx> wrote:

> Hi Jeff:
>
> Is it Sunday already? Must be time to lose the rest of the weekend in a
> discussion with Jeff :-)

...and a fine discussion it is too. May I join in?
>
> On 16/9/05 12:15 AM, in article #vrzl$fuFHA.904@xxxxxxxxxxxxxxxxxxxx, "Jeff
> Wiseman" <throwawayacct223@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
><snip>
> > I've used X
> > windows, Solaris, and Openwindows on sun workstations and they
> > all seem to have that same type of sluggishness. In fact OS X
> > seems to have the edge in terms of "feel" but that may simply be
> > because I've only used it on workstations that are faster than
> > the ones using the other interfaces.
>
> Yes, they do. But I am not sure that's the fault of Unix. I suspect that
> part of that is due to application software vendors being unwilling to
> re-architect their applications for a multi-threading, multi-tasking
> environment.

<snip>

> Unix has a bad habit
> of defaulting to a 20 milli-second time-slice. Keeping the maths simple,
> every application gets handed 40,000,000 instructions worth of processing
> each time its request is answered. The OS won't look again, or give time to
> anyone else, until 200 milliseconds go by. Now, that kind of allocation is
> fine if you want to typeset the Gettysberg Address. It was fin back in the
> days when CPUs ran at eight million instructions per second. It might even
> work today on a mainframe processing a large batch job. But to decide that
> the user has pressed the letter "b" and send the content of the keyboard
> buffer to Word? Gimme a break!
>
> So the first thing you can do to make an OS seem responsive is to cut those
> time slices way back. Windows XP uses really short time slices, and thus
> hands out a lot more of them. No application ever has to wait "long" to get
> the computer's attention.

You know very well that is not the whole story. Both Unix and NT will
consider rescheduling threads on every significant interrupt, only one
of which is the clock tick that expires a time slice interval. I/O
completing earlier in another thread does just as well. Both NT and OS
X do their scheduling via 'kernel threads'. The time slicing comes into
play only when nothing esle is happening and more than one
compute-bound thread is competing for the processor's attention.
>
> Then we can start playing around with Thread Priority. The way thread
> priority works is that the OS hands out a hundred slices to the "High"
> priority tasks, then 10 to the "medium" priority tasks, and then 1 to the
> "low" priority tasks. The task waiting longest gets the slice handed out
> next in each category (there are actually 255 priorities, but you get the
> idea). Both Unix and Windows enable an application to adjust their
> priorities. If the application has nothing to do, when it next gets a time
> slice it responds with "Nothing to do and set my priority to 'low'". If
> Acrobat Reader was sitting in the background it would set its priority to
> 'low". Then you open a PDF. Reader then tells the OS on the next time
> slice "Really busy, jump me to High and call the ATSUI rendering engine for
> me." Adjusting thread priorities is an art, not a science :-) If an
> application designer gets his thread priority too low, his application is
> unresponsive. If he gets it too high, his application slows the whole
> system down and he loses sales. In between, there's a sweet spot that seems
> responsive to the user, without draining too much system resource or
> interfering with other applications. Unfortunately, the sweet spot depends
> on what else is installed and running at the time. And the application
> designer can't know that...
... of course it simpler than that for the administrator of the machine,
who does not need or even get too many tools to play with. (nice and
renice) Threads are scheduled for execution strictly by priority, but
the scheduler plays with compute intensive thread priority on-the-fly
within a 'round-robin-range' to deal out resource fairly.

> A way around that is to design the application for multithreading. Nearly
> all of the applications that existed before OS X and Windows NT were
> "single-threaded". Their code was one large single piece. There was no
> point in splitting them up. The application would start, do what it had to
> do, then exit. Only one application could be running at a time, and it
> would exit when it was finished. So there was no performance benefit in
> splitting it into multiple pieces: quite the reverse.
>
> Now, there is a benefit in doing that. You put the tasks the user will want
> to do frequently in small modules that can exit quickly. You run these
> modules at high priority. The system seems responsive to the user. You put
> the things the user does not need to be involved with into different pieces,
> and run them at a lower priority. Since the user never needs to be
> involved, he doesn't know how long they take and doesn't care. Best of both
> worlds: the system seems far more responsive and the computer runs very
> efficiently.
I think you are comparing pre-emptive and co-operative scheduling. In
OS9 and earlier, if a compute bound process hogged the machine, nothing
else would be scheduled until it gave the OS permission to do so.
Typical might be a four hour video render that would not even allow the
menubar clock to advance, let alone permit the user to join in debate
with John and Jeff on usenet. That was co-operative scheduling. When
done well by every program in the machine it was very very good, but
when one went bad, it was horrid.

Timeslicing is old-style unix's method of permitting many processes to
pretend to execute at once. You do get something for nothing. When one
slice is waiting for I/O, another can run before the first's slice
expires. With old-style Mac OS, the unco-operative process was
permitted to sit there going 'la-la-la I can't hear' you till the disk
finished getting his stuff. That is simple pre-emptive scheduling. The
timeslice expiry cut Mr La-la off at the pass.

With kernel thread scheduling, as in NT and OS X, the author of an
individual process gets the option of writing a mini-operating sytem
just for his own program. Like multiply buffering asynchronous I/O, so
he can get some of his own work done while waiting for his own I/O, as
well as responding quickly to user interaction interrupts, like
keystrokes and mouse moves and clicks.
>
> But splitting an application up is horrendously complex and difficult to
> test, because all of the pieces may depend on work being done by another
> piece. So application designers won't attempt it unless they can begin
> their design that way.
So true.
>
> Most "modern" applications have never gotten beyond "idle loop processing".
> This is a sort of "cheat" multi-tasking. You take all of the bits that
> interact with the user and put them in the Main thread. You take everything
> else (all the bits that actually perform work) and place them into the Idle
> Loop. The main Thread runs very frequently to check if the user wants to do
> something, then falls quiet and calls its Idle Loop. Word uses this
> technique. While you are typing, or moving the mouse, Word is doing nothing
> but listen to you. When you stop typing or stop moving the mouse, that's
> when Word begins to process the information you have given it. Pagination,
> spelling, grammar, printing: all of those things happen only when you stop
> to think. This technique benefits the whole system: if everyone builds
> their applications this way, the system is much more responsive, and the
> "work", the actual "processing" gets done only when the user doesn't want
> the system for something else.
Yep, what you describe is the GUI curse. Horrid, horrid callback land.
>
> But it also leads to some peculiar effects. The "Beachball" is one. Word
> calls a high-priority interrupt when it needs to display what has happened
> as a result of something you have done. But it then needs to sit there and
> wait until the background task (the idle loop) gets enough time in the CPU
> to complete making up the thing to be displayed. You and I get to watch the
> beachball until that happens. Cunning old farts like me know that Word is
> waiting for the idle loop to get some time. We know it will get some time
> right after the Main loop completes each time. And we know that if we click
> the mouse button, the main loop will be called. So if you want the
> beachball to stop and show you what you typed, click the mouse :-)

...if you are lucky. You at the mercy of the application's designer for
that to happen.
>
> > For that reason, I suspect that it's going to be hard to again
> > match the great responsiveness and feel of a single user pseudo
> > multitasking OS such as the original Mac where you could sizzle
> > through operation after operation and the computer could actually
> > keep up with you.

You had a better experience of that than I remember. I hated it.
>
> No. But it is a LOT of laborious detailed work, splitting applications up
> into multiple threads, adjusting the priorities of each, tweaking their
> priorities, coding, and testing. It doesn't add ANY "new features" that you
> could give to Marketing to SELL. But it has a very high chance of adding
> LOTS of lovely new BUGS -- timing issues where the justification routine
> crashes because it was waiting for the pagination routine which was waiting
> for the printing routine when all three were interrupted by the user hitting
> the delete key...

Nah. All you have to do is get out of the callback loop mindset. Done
right, it is easier than before. Done wrong, it is a similar disaster.
A great example of wrong is Tiger's finder spotlight search. Boy, is
*that* a 'work-in-progress'. Or Tiger's mail. They have introduced an
interesting race between the threads that list mailbox content. Scroll
the mailbox list too fast and the messages appear as if in the wrong
mailbox.

Hmm. I have made your point for you, haven't I? Done right, threaded
applications are easy. Honest! (I was brought up properly in VMS and
RSX before that, where asynch queued I/O with AST's (Asynchronous
System Traps) was the norm. Even there, we got the same callback
nightmares with the X11 Windowing system.)
>
> This is not something software vendors are actually "enthusiastic" about.
> The move to MacIntel may assist them to learn to love it :-) Not that
> anyone in the computer industry has EVER run out of excuses or the ability
> to point the finger somewhere else to blame someone else.
>
> But they will need to be a little more inventive to come up with a
> convincing excuse when we point out that "your application runs ten times
> faster on Mac OS than it does on Windows OS using the same computer to
> process the same file." Might have to fix it then...

That is one competition I'm watching with interest. Much as I like OS
X, I think the NT kernel's scheduler will be hard to beat. I will be
very surprised if OS X is faster on identical machines in that
department.

--
To de-mung my e-mail address:- fsnospam$elliott$$
PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248
.