mjs@ernie.Berkeley.EDU (Marc J. Sabatella) (05/09/88)
As part of a project in a compiler class, I recently translated an assembly language version of a lexical scanner for Ada into C, and was quite shocked at some of the benchmark results I obtained. On my 4.77/10 Mhz switchable clone, the assembly language version of the program consistently runs 5-15% FASTER at 4.77 Mhz than at 10. I am intimately familiar with the source, and it doesn't do anything extraordinary with the timing. It uses the DOS block I/O functions to read in 32K chunks at a time; the inversion is most pronounced when only one chunk is read (ie, the Ada source program it is scanning is less the 32K), but exists one inputs as large as 5 MB. The effect is more exaggerated on floppy than on hard disk, and less so on ramdisk (but still occurs for small input files). I tried it from floppy disk on a friend's AT clone which also has a switchable clock rate, with similar effect. The C language transliteration of the program exhibits the same behavior for small input files (under 1MB or so). The C language version uses the same input routine. I tried the experiment using the standard C fgets() function (both in the assembly version and in the C version) from the Turbo C library, as well as the Datalight C library, which do I/O in much smaller chunks, and got the same results. Can anyone offer a decent explanation of this? [Usually the speedup in clock rate speeds up semi-I/O bound operations like compilers by about 50%, rather than slow them down!] ---------------------- ------------------------------ Marc Sabatella "I would prefer not to" mjs@ernie.Berkeley.EDU Bartleby the Scrivener ---------------------- ------------------------------
kahn@xanth.cs.odu.edu (Gary I Kahn) (05/11/88)
Any disk access on a turbo PC clone probably slows the processor speed to 4.77MHz. This is because the floppy drive can't be accessed at, say, 8 MHz if it is IBM compatible. As a result, on my clone, every interrupt 13 (disk access) is grabbed before execution, and a short program is run to slow the clock speed. After the disk access is completed, the same program has to execute more code to speed things back up. This means that a 8MHz clone might execute a disk-intensive program slower than a standard 4.77MHz machine. If the computer is running at the slower speed, the excess code isn't needed on each interrupt 13. I've noticed that the CORE test suite shows lower throughput on my hard disk controller if I'm running at turbo speed than at standard speed.