richards (07/07/82)
#N:uiucdcs:21700005:000:862 uiucdcs!richards Jul 7 15:34:00 1982 A first set of (crude) timing data has been obtained on our iAPX432 development system. These runs were a main program written in ADA, compiled using the Unix(tm) pre-release of the 432 Cross Development System and run on the 432/670 with release 2 GDP's: Statement (repeated 1,000,000 times) Elapsed Time Statement Time null; 1:00.00 -- v1 := v2 + v3; (All 32-bit integers) 1:21.0 21 microsec v1 := v2 * v3; ------- " --------- 1:29.0 29 microsec v1 := v2 / v3; ------- " --------- 1:38.0 38 microsec The times were taken by hand -- the operating system kernel (iMAX432 V2) doesn't allow access to the process clock that the 432 keeps for each process... Code sequences for each statement was very clean (one instruction for each non-null statement above), but the loop had *2* termination tests. I'll post the call/return timings shortly. -paul
richards (07/08/82)
#N:uiucdcs:21700008:000:408 uiucdcs!richards Jul 7 20:11:00 1982 Subroutine calls are indeed slow! -- This is what I got on the first test... 100,000 calls to a no-argument subroutine took 1:09.0 - the loop overhead counts for 0:06.0 of that (see previous note), so we are talking of about 603 microseconds per call??? I'll look at the call instruction to see exactly what it does, and what the return instruction (the only code generated for a null body subroutine)....
richards (07/08/82)
#R:uiucdcs:21700008:uiucdcs:21700009:000:431 uiucdcs!richards Jul 8 13:41:00 1982 I believe that the timing is correct. Some of the overhead may be caused by the iMAX operating system. When you return from a context, all the objects owned by that context are freed up. It may be that upon return, the iMAX object/memory garbage collector is jumping in at a higher priority and reclaiming/compacting the "normal" memory group for me. Anyone else have ideas other than "it's just overhead of Call_With_Message"?