dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/03/86)
This is Re: to Michael Wagner's Re: to the multi-tasking overhead discussion. SYSTEM OVERHEAD TIMING TESTS: I did these tests with a standard Amiga running under a CLI (E.G. WITHOUT WorkBench). By openning up my Amiga, I found the Crystal to be 28.6363 Mhz scaled down by 4. This results is a 7.15908 Mhz clock. (1.2 Gamma) My Amiga has only 512K currently, so all tests were done in CHIP memory. Each test involves openning the specified screen so it is the only screen visible. Three trials are done per screen; the final result shown is the average. HOWEVER all time values in a 3 trial set were within 1/10 of a second of each other anyway. Unless otherwise noted, the delay loop is done as a normal, user program, with all normal system stuff running, and no interrupts disabled (e.g. a normal system). Apart from the system, the test program is the only task running. 7.15908 Mhz is 7,159,075 clocks per second. The test inner loop is as follows: LOOP SUBQ.L #1,D0 ;8cc BNE LOOP ;10cc total is 18cc An initial value for D0 of 23,863,583 should yield exactly 60 seconds if the program gets 100% of the CPU (AND assuming the CPU gets the bus whenever it wants it): 23,863,583 * 18 / 60 = 7,159,074 counts cc/cnt secs/min cc/second Thus, for the results below, a value of 60 seconds represents optimal: 429,544,494 cc / trial (23,863,583 counts on the assembly given above) (TIME +/- .1 second) (Unless otherwise noted, SYSTEM OVERHEAD takes into account the specified screen, and any overhead from system tasks, interrupts, etc...) NON INTERLACE SCREENS TIME EFFECTIVE CC/SEC SYSTEM OVERHEAD (sec) 320x200x1 66.6 6,449,617 9.9 % 320x200x2 67.7 6,344,822 11.4 % 320x200x3 67.7 6,344,822 11.4 % 320x200x4 67.7 6,344,822 11.4 % 320x200x5 74.1 5,796,821 19.0 % HAMx200x6 85 5,053,464 29.4 % 640x200x1 67.7 6,344,822 11.4 % 640x200x2 67.8 6,335,464 11.5 % (NI WORKBENCH SCR) 640x200x3 85.1 5,047,526 29.5 % 640x200x4 148.4 2,894,504 59.6 % INTERLACE SCREENS TIME EFFECTIVE CC/SEC SYSTEM OVERHEAD (sec) 320x400x1 66.7 6,439,947 10.0 % 320x400x2 67.8 6,335,464 11.5 % 320x400x3 67.8 6,335,464 11.5 % 320x400x4 67.8 6,335,464 11.5 % 320x400x5 74.1 5,796,821 19.0 % HAMx200x6 85.1 2,884,785 29.5 % 640x400x1 67.8 6,335,464 11.5 % 640x400x2 67.8 6,335,464 11.5 % (LACE WORKBENCH SCR) 640x400x3 85.1 5,029,795 29.5 % 640x400x4 148.9 2,884,785 59.7 % ADDITIONAL TESTS 320x200x0 64.2 6,690,724 6.5 % 320x200x0 * 62.1 6,916,980 3.4 % 640x100x4 89.6 4,794,023 33.0 % Data compiled by Matthew Dillon. * This test was done within a Forbid() and Permit(). Yes, that *is* a 320x200xZERO screen. No bit planes. I got a blank screen (Unless OpenScreen() is doing something I don't know about). It shows about 6.5 % overhead. 6.5 % is still quite a chunk out of the processor, what could the system be doing? Further Investigation shows that half of that 6.5% is taken up by the running of system processes. The remaining 3.4 % is taken up by, I guess, Interrupts and the co-processor. 3.4% is about 4057 clocks per second, or about 68 clocks every 1/60'th of a second. It seems reasonable, but I would like to put the question to C-A as to which system-tasks are being run that causes another 3.1% to be slapped on when the test is run under normal system operation??? The 640x100x4 screen using only half the CPU as the 640x200x4 screen is no surprise; neither is the fact that INTERLACE makes NO DIFFERENCE, since the full image is scanned every 1/30 second (double the resolution without doubling the scan rate). -Matt ----------------------------------------------------------------------