[comp.unix.i386] Cache vs. Mhz

chaiklin@cunixf.cc.columbia.edu (Seth Chaiklin) (07/25/90)

I have a dilemma.  I must take either a 25 Mhz 386 machine
with no cache or a 20 Mhz 386 machine with a 64K cache.
I will run SCO Xenix 2.3.1 on this machine.  I am interested
to know what the implications are for going with one setup
over the other.  Does SCO Xenix take advantage of the
cache?  Or would the increased speed offset any advantage
of the cache.  Thanks for your opinions.

------------------------------------------------------------------------------
Seth Chaiklin         Institute for Learning Technologies
(212) 678-3899        Box 8, Teachers College, Columbia University, NYC 10027
INTERNET:  chaiklin@cunixf.cc.columbia.edu    UUCP:  seth@ny-yn
------------------------------------------------------------------------------

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (07/26/90)

In article <1990Jul25.030258.11568@cunixf.cc.columbia.edu> chaiklin@cunixf.cc.columbia.edu (Seth Chaiklin) writes:
| 
| I have a dilemma.  I must take either a 25 Mhz 386 machine
| with no cache or a 20 Mhz 386 machine with a 64K cache.

  Since anything which runs on the CPU uses the cahce (unless you turn
it off) the choice of o/s is not a problem. The choice of faster or
slower depends on your floating point use. If you are going to use a
coprocessor and do lots of f.p. you might see it faster with the 25MHz.
For almost any other application I would go with the 20MHz and cache.
The cache will give you about 15% improvement with a 1w/s memory. I
would be very sure whats happening if the 25MHz machine claims to be
0w/s, unless it is running fast interleaved memory.

  I don't think there will be a great deal of diference in performance
in these, oddly enough, so I doubt that you can make a seriously bad
decision.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

chaiklin@cunixf.cc.columbia.edu (Seth Chaiklin) (08/02/90)

I recently posted a question about the tradeoff between a memory
cache and clock speed (specifically, 25 Mhz w/o cache vs. 20 Mhz
w/cache). The general consensus is that cache will give you
better performance (and save you some money as well).
 
Here is a summary of the relevant responses (all cited with
permission.)  I have posted this to the three groups where the
question was originally posted, and have put followups to
comp.unix.questions.
 
================================================================
 
From gwr@linus.mitre.org Wed Jul 25 17:36:49 1990
 
I would go with the Cache.  It will improve the execution speed, and
more importantly, it can make later expansion of main memory less
expensive.  In my comparison, the caching board allowed use of slower,
less expensive (100 nS.) main memory while the equivalent speed
non-caching board needed more expensive 80 nS RAM.
 
--------------------------------
From gwr@linus.mitre.org Thu Jul 26 12:51:55 1990
 
All the cache boards I'v heard of cache _physical_ addresses
(and data) so it doesn't matter what software is running, only what
degree of locality the software maintains in its memory references.
 
Many boards, (like my MYLEX and the Micronics, maybe others) have
farily small (4-byte) granularity in the cache and can achieve a
respectable "hit/miss" ratio even with only 32K or 64K of SRAM.
 
I hate to quote such a meaningless number, but my 20 MHz MYLEX with
64K SRAM cache (0-wait-states) and 1-wait-state main memory runs
the "landmark" speed test at "AT equivalent" speed of about 32 MHz.
Take this "with a grain of salt" as I've noticed that the "landmark"
speeds are based on the speed of linear, sequential memory access
(which is definitely NOT the norm) and therefore tend to favor
interleaved memory architectures (fastest with sequential access).
By contrast, cache boards do best with a small memory reference set,
regardless of the alignment and order of access within that set.
 
Beyond this hand-waving, all you can do is compare the execution time
of the two boxes with _your_ application (and similar hard disk).
All that matters is how long it takes your program to finish.
 
By the way, I recommend the MYLEX board (made in Freemont, CA).
The board is very well made, warrantied for 2 years, and well
supported by the maker.  I got new ROMS from them for free!
They will also supply new PALs to let you use various memory-mapped
devices beyond 1MB (i.e. multi-port cards under UNIX).  The new PAL is
needed if you want to disable caching for certain memory addresses.
Normally caching is enabled in 0-640K and 1MB-16MB.
 
Gordon W. Ross			*net: gwr@linus.mitre.org
The MITRE Corporation		uucp: {decvax,philabs}!linus!gwr
Bedford, MA 01730 (U.S.A.)	phone (day): 617-271-3205
 
 
----------------------------------------------------------------------
 
From csinc!rpeglar@uunet.UU.NET Thu Jul 26 09:52:27 1990
 
take the cache.  for real-world applications, cache will be a far bigger
win.
 
------------------
 
From csinc!rpeglar@uunet.UU.NET Thu Jul 26 17:20:30 1990
 
> Thanks for the word about cache....Does it make any difference
> though if we are running under Xenix.  I have been told that
> Unix does not really make much use of a memory cache.
 
Cache is "invisible" to the OS, in terms of instructions and
data.   The code, data, and stack portions that make up all Unix
executables  are all coming from RAM;  whether the specific area
of RAM is cached or not is immaterial.  Caching speeds up access
(from the 2nd through nth times) to code and data, nothing more.
 
In fact, Unix would exercise a cache far more due to its multitasking,
multiuser architecture.  Cache helps a multiuser system far more than
a singleuser system.
 
Rob
 
 
-- 
Rob Peglar	Comtrol Corp.	2675 Patton Rd., St. Paul MN 55113
		A Control Systems Company	(800) 926-6876
 
...uunet!csinc!rpeglar
 
----------------------------------------------------------------------
From small@quiche.cs.mcgill.ca Thu Jul 26 13:19:58 1990
 
	Hi!  To give you a hint: A 25Mhz with 64k do 1690% in the
	PCTools (I now but you will be able to evaluate) and a 25
	no cache climb at 1369% and a 20Mhz DTK PEM-2000 (this board
	is a little special) do around 1005% and a Arche Profile
	386/20 do 850%.  If you have a CT&T ChipSet on your board
	you will get some kind of a drop of performance in <Access
	of RAM> because this Set Emulate a LIM 4.0 Expanded Memory,
	have Shadow RAM and some others goodies.  Personaly: DON'T
	BUY A BOARD WITH CT&T (More likely call: C(heaps)T&T... The
	DTK Board dont have those chips and the Arche does... ;-}
 
	Bye...
-- 
------------------------------------------------------------------
small@quiche.cs.mcgill.ca   | 
McGill University           | Life is the primary cause for Death.
Montreal, Quebec            |
 
----------------------------------------------------------------------
 
From ssc!Phil.Hughes@celestial.com Thu Jul 26 20:36:07 1990
 
I would pick the 20MHz cache system.  The numbers I have seen for 16MHz
cache systems (which we run with SCO Xenix) indicate that it performs
about as well as an equivalent 23MHz system.
---
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
     uunet!pilchuck!ssc!fyl or attmail!ssc!fyl            (206)527-3385
 
----------------------------------------------------------------------
 
From gary  Wed, 25 Jul 90 22:16:12 CDT remote from cdthq
 
I'd go with the cache machine. The throughput from the caches' 
response should easily exceed the 25% the faster clock will 
give you. The caches' existance will be invisible to Xenix.
 
Wish I had dilemmas like this.... :-)
 
Gary Heston, at home....
 
P.S. We make some cache machines at work. Email me as
gary@sci34hub.sci.com and I'll see if I can find some comparative
performance info. I'm sure we have some around, somewhere.
----------------------------------------------------------------------
 
From hatton@cgl.ucsf.EDU Wed Jul 25 01:53:59 1990
 
      In general, if memory serves, any 25MHz uncached beats even the
best-cached 20MHz according to *benchmarks*. whether this holds up in
real life situations is perhaps questionable, but I think it probably
holds.
================================================================
 
From sci34hub!gary@uunet.UU.NET Tue Jul 31 17:47:03 1990
 
 
Some Comparative Results of Cached/Non-Cached Systems
Benchmarking
 
Note: I didn't run these tests, I just got the info from somebody who
did. Your results may vary, and particularly the specific software you
run can have different results from a benchmark. All these tests are
computational only, they did not check any IO speeds.
 
System Descriptions:
 
All systems were 386 machines using 32-bit memory cards. I believe
all the systems had coprocessors. Details:
 
System  Clock   Cache
 
AST     20Mhz   16K
300     16Mhz   none
304     20Mhz   none
325     25Mhz   32K
333     33Mhz   32K
 
Notes: The AST was bought for comparative testing. The others are our
products, of which the 300 is discontinued. I'm including it as a base
reference, since there's lots of 16Mhz 386s out there, and everyone
knows pretty well how they perform.
 
System          Sieve           Dhrystone       Aggregate
AST              .671 sec       5,652/sec       469.002 "PMU"s
300             1.255           3,501           261.568
304              .938           4,648           349.780
325              .509           7,548           658.456
333              .371           8,891           831.969
 
These were resultes from something referred to as "Power Meter", and
the "PMU"s in the aggregate test are aparently "Power Meter Units".
I haven't got the foggiest idea what they mean. Interpret these as
you wish. Take with a grain of salt, unless you're on a sodium-restricted
diet. :-)
 
Now, to forestall an avalanche of email.....
 
I'm a site admin; I don't have anything to do with the sales or pricing
of our products. We generally sell to VARs and distributors instead of
individuals. If anyone really wants information, I'll forward mail to
someone who should be able to help you.. In general, you'll get a better
single-unit price and faster delivery from mail-order houses, because
we're set up to handle people who want hundred or thousand quantities.
This is a disclaimer, not a commercial, so let's not start a flame war...
Have a nice day.
 
 
    Gary Heston     { uunet!sci34hub!gary  }    System Mismanager
   SCI Technology, Inc.  OEM Products Department  (i.e., computers)
"The esteemed gentlebeing says I called him a liar. It's true, and I
regret that." Retief, in "Retiefs' Ransom" by Keith Laumer.
=======================================

Finally, I spoke to a person in tech support at AMI. He ran the
Landmark speed test on his machines (sorry no further information
about their configuration).  The 20 Mhz cached gave a 31.6, while
the 25 Mhz uncached gave 23 or 24.  

Enjoy,
  Seth Chaiklin