Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
From: jwil1@cs.aukuni.ac.nz (TMOTA)
Date: Mon, 9 Nov 1992 00:19:53 GMT
Organization: Computer Science Dept. University of Auckland

steve@acorn.co.uk (Steve "daffy" Hunt) writes:

>Response time in a co-operative system is completely at the mercy of
>all the other programs running.  Each "co-operating" task has

Yup. So long as everyone *cooperates*, it runs fine.

>absolutely no way to determine how much work it should do before
>relinquishing control.  In general it is an impossible task to write
>code for a background operation that maximises its own performance
>without taking an unacceptable toll on system throughput.

Hmmm... I think that's a load of bollocks, but if I say that you'll get
upset... ;-)

Firstly, there IS a way to determine "how much work...before relinquishing
control". You give yourself a TIMESLICE. That is, your own program
pre-empts ITSELF (or pretends to). A timeslice is also a good idea, as
TIME is constant on all processors, while instructions-per-second isn't.

DSEdit II background multitasks. It has a preference option for how many
centi-seconds to take for each task 'timeslice', so the user can tune it
to the required level.

The default is 15cs. This means that you typically get 5 or 6 polls every
second, which gives a response time close enough to 'no-load response'
that most people don't notice it.

However, I did a lot of experimenting with other timeslices: Any timeslice
above 20cs made *unmeasurable* difference to to overall performance of
my code (One function had an upper-speed-limit of about 100kB per second,
and at 20cs timeslices, it ploughed through... 100kB every second.)

This is because the time lost when you poll the WIMP and it polls around other
applications and then gets back to you with a NULL poll is VERY small
compared to a 20cs processing slice - this on an ARM-2 with about 10 to 15
tasks idling... 5 polls a second take very little toll on the CPU.

If you drop the timeslice down to (say) 5cs, then you get *slightly* better
response time (about 20 polls per second), but the overhead for doing the
polls starts to become noticable, and the performance drops off. This is
especially noticeable when the timeslice gets so small that you spend most
of your time Polling, and processing the timeslicing, and very little time
actually processing: a timeslice of 1cs was enough to bring the process
down to only about 20kB per second throughput.

>A well-designed pre-emptive system gives you this for free.

Yup. And about 3 minutes work on a RISC OS application is all that's needed
to achieve the same.

In DSEdit, I use the following scheme:

Wimp_Poll
If there's a task running, then
  Add a CallBack with the code: STR r12,[r12]: MOV PC,R14
  (with the 'R12' value being the address of a flagword in memory)
  Set flagword = 0
  Start Processing., This goes in a loop of the form:
    while (not_finished && flagword == 0) process;
endif
[loop back to Wimp_Poll]

As soon as my timeslice is up, the callback causes the flagword to be
set to a non-zero value. The very next iteration of the loop will cause
processing to be interrupted for another poll. Thus, if I set a timeslice
of 20centiseconds, my application will take *marginally* more than 20cs
(20cs plus a few instructions).

So long as you check the flagword often enough, this works extremely well,
with a very very small processor overhead for timeslice maintenance.

>Co-operative tasking can be very lightweight and this can give an
>impression of great snappiness when other tasks are idle, but as soon
>as there is background work things tend to deteriorate very quickly.

NO!
You base this on what?
The only applications that 'background' that I have used much are:
  TaskWindow: Uses too large a timeslice, so makes desktop jerky. Should
	      have a user configuration option.
  Filing/
  Spark:      Timeslices well, but is I/O bound, which can often mean it
	      is unable to Wimp_Poll for a long period of time while data
	      is read/written from/to slow devices such as floppies.

I have yet to use any program (apart from DSEdit II) that multitasks
'properly' in the background. What I mean by this is:
  * TIME-sliced: A timer is used (rather than number-of-bytes-processed or
		 some other arbitrary measure which changes when you move
		 to a different processor)
  * TimeSlices are adhered to. i.e. the Filer can't guarantee that an operation
		 will be completed within 15cs. DSEdit does adhere to the
		 timeslice, as it can 'pause' processing at a much smaller
		 time-step than 15cs.
  * The USER gets an OPTION to set the timeslice value. They can therefore
		 use completely-backgrounded values like 5cs (slows the
		 process, but they don't ever notice it) or 20cs (maximum
		 throughput, but the desktop becomes jerky).

Just because you haven't seen a good multitasker under RISC OS, don't think
that it means it isn't possible: It IS, but programmers haven't yet twigged
to how EASY it is to do PROPERLY.
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)
Newsgroups: comp.sys.acorn.advocacy