Path: utzoo!utgpu!watmath!clyde!att!ucbvax!ucdavis!iris!finley
From: finley@iris.ucdavis.edu (Curtis M. Finley)
Newsgroups: comp.sys.encore
Subject: Timing on the Multimax
Message-ID: <3273@ucdavis.ucdavis.edu>
Date: 11 Nov 88 18:49:22 GMT
Sender: uucp@ucdavis.ucdavis.edu
Reply-To: finley@iris.ucdavis.edu (Curtis M. Finley)
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Lines: 51

I'm studying the performance of a program which makes use of the 
multitasking library.  (I realize threads is supposed to be better 
than multitasking but I started the project before threads was 
available.)  I'm using /bin/time to look at real, user, and system 
times with various numbers of processes at various levels of work.  
I'm having trouble explaining some of the times.  I'd appreciate it if 
you could give me some help. 

What goes into "system time".  Do calls to the multitasking library 
accumulate system time or user time?  It would appear that time spent 
in task_init accumulates system time.  What about spin locks, 
task_start, task_stop, share_malloc, and task_self?  What about I/O 
for the management of virtual memory?  I assume the instructions which 
cause I/O for virtual memory cause an accumulation of system time.  Is 
the time for disk access and data transfer accumulated under system 
time or does it account for part of the discrepancy between real time 
and the sum of system and user time. 

My experience is that task_init can take a tremendous amount of system 
time when three or more processes are being started.  The amount of 
system time is directly related to the amount of shared memory being 
reserved.  Why does the amount of memory make a difference?  It would 
seem that the memory is virtual and that it should have no effect 
until accessed. 

I wrote a concurrent program using multitasking and ran the program 
several times varying the amount of work done in the concurrent tasks.  
The program reserves 35MB shared memory but doesn't use most of it.  A 
plot of work vs system time shows a "staircase" effect.  As more work 
is done, system time increases then levels off, increases then levels 
off, increases then levels off ....  The increases are about 0.4 to 
0.6 seconds.  The stepping occurs more when there are a large number 
of processes (20) and less when there are fewer (4).  Stepping is less 
pronounced when only 3MB shared memory is reserved.  One thought I had 
is that the step up is due to time required to keep track of memory 
for multiple processes at the time of a context switch.  This argument 
is flawed since we have six processors and the stepping still occurs 
when the number of processes is less than six.  Timings were done 
while the machine was practically idle and there should not be any 
context switches.  

Does UMAX handle processes started with task_init as a unit?  That is, 
are they time-sliced simultaneously or are they completely independent?  
Presumably they are independent but if they are not perhaps that could 
help explain the stepping described above. 

My timing studies indicate that programs using multitasking have to do 
a tremendous amount of parallel computation to out perform programs 
with a single thread of control.  This is mainly due to the large 
system overhead of starting the multitasking environment.   Is threads 
significantly better in this respect?