Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!aplcen!haven!rutgers!att!dptg!pegasus!dmt
From: dmt@pegasus.ATT.COM (Dave Tutelman)
Newsgroups: comp.sys.ibm.pc
Subject: Re: (Disk) Cache problems...
Message-ID: <4276@pegasus.ATT.COM>
Date: 28 Nov 89 13:28:01 GMT
References: <638@ariadne.csi.forth.GR> <206900142@prism>
Reply-To: dmt@pegasus.ATT.COM (Dave Tutelman)
Organization: AT&T Bell Labs - Lincroft, NJ
Lines: 55

In article <206900142@prism> rob@prism.TMC.COM writes:
>
>>Problem : CACHE programs.
>>Machine : IBM AT 6Mhz, 30 Meg. Hard disk, 1.5 Meg. extended memory.
>>Symptom : 
>>                         No Cache     |  PC-CACHE  
>>                        --------------+---------------
>>          Norton's DI      1.9        |    4.9    
>>          Coretest       202.9 Kb/sec |  985.6 Kb/sec
>>          Compiling       77 sec      |   75 sec
>
>   Two things - first, on a 6Mhz machine, the disk is probably not your
>real bottleneck unless it's a very slow disk. As a result, speeding up
>your disk access times can only go so far to speed up your overall
>compile times.

I beg to [partially] differ.  I have run compiles on 3 machines:
   1-	An old AT&T PC6300 (8086 @ 8MHz, 65 ms disk).
   2-	An AT&T PC6300 PLUS (80286 @ 6 MHz, 65 ms disk).
   3-	An AT&T 6386SX WGS (80386SX @ 16 MHz, ~30 ms disk).
The PLUS has a 1MB disk cache in extended memory.
The SX has room for a cache, but I haven't gotten around to adding it yet.

The speed ratios are roughly 2 : 5 : 8  PLUS has cache, and
			     2 : 3 : 8  all without cache.
These numbers are for production compilation of C programs in excess
of 3000 lines (including some in excess of 30,000 lines).  The programs
were modular, in that very few files exceeded 500 lines.  The ratios
were quite consistent across program size, and consistent within
compiler type (Microsoft C, Turbo C command-line, and Turbo C integrated).

That's a pretty dramatic improvement for the PLUS (60-70% speedup). 
There's no way a 6MHz 286 with slow disk should run at more
than half the speed of a 16 MHz 386SX with fast disk.
I attribute it to some of the points mentioned here by
[don't remember who, but s/he's right].
The cache is big enough that the compiler and header files can remain in
cache (even with .C, .OBJ, and temp file activity). 
In a big program with lots of small files,
much of the compile time is spent reading in headers.  You can even
WATCH (in Turbo C integrated environment) how much faster the later
files compile than the first.  And putting the compiler in RAMdrive can
assure that reloading it isn't a timewaster.

I guess I just made a pretty strong case for adding a cache to my
workhorse 6386SX.  My current work assignment takes 25 minutes for a
clobber-make on the SX.  Of course its disk isn't nearly as much of a
timewaster as the slow disk on the PLUS, but I bet it'd help.

+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Lincroft, NJ			|
|    Logical -  ...att!pegasus!dmt				|
|    Audible -  (201) 576 2194					|
+---------------------------------------------------------------+