Newsgroups: comp.sys.transputer
From: ifunltd@xs1.xs4all.nl (ifunltd)
Subject: Re: measure execution time on T800
Organization: XS4ALL, networking for the masses
Date: 19 Nov 1994 07:56:00 GMT
Message-ID: <3akb2g$ja6@news.xs4all.nl>

Lothar Berger (eeberger@hope) wrote:
: Hi,
: My assignment is the measurement (extraction) of execution time of procedures
: written in Parallel C running on the following target machine: T800 on a IP1 
: TRAM on a B008 in a PC

: figure:

: mytask (low prio)   ***********        *********   ***********************
: 2nd task (low prio)            ********          
: scheduling			     	        *
: urgent task			  	         **		


: time for mytask =  |----------|  +      |-------|  + |--------------------|

: time for 2nd task =            |-------|


You cannot ask the transputer to give you all the timings, that would make
it as slow as for example Unix. What you can do is use a statictical
approach: have a separate HI-Pri process check on the active process queueu
every short timestep. Of course this kills the performance of the transputer
but you can subtract the time needed for the introduced HI-Pri process by
counting its cycles, or even by having this process read the timer when it
is activated and just before it deschedules. One effect you will not be
able to avoid in this method is that the overall timing of the program
will be affected (since some I/O takes place over links and this overlaps
with the normal tasks but also with the time introduced for the HI-Pri
measurement process). And in the end you will have only an approximation
of running times of all processes (not of procedures inside processes).

Another way would be to have all code (except explicit or implicit I/O
or waiting for timers and events) produced non-interruptable (I am not
sure whether this is possible in your programming environment) and 
introduce your own time-measurement in each of the procedures: keep on
reading the time and subtracting the starttime of each portion of the
work, and do so before each possible descheduling point. This of course
not only kills the overall timing, but also the source code of the program.

A lot of people have been working on performance measurement on transputers
with different levels of granularity. Also, some of these efforts have led
to products or non-commercial tools available possibly at University sites
or maybe even at some ftp archive. Try to hunt for contacts at HENSA.
If you mean Inmos C Toolset with your "Parallel C" you may want to look
at the Advanced Toolset, which includes a performance measuring tool.
I have not used it, so I don't know how good it is. But since you would
be facing a lot of work (and problems I guess) in building your own, it
might be useful to hunt around some more before starting or continuing
your coding.

Good Luck

Jang

