Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!sdd.hp.com!think.com!news!everettm
From: everettm@mickey.think.com (Mark Everett)
Newsgroups: comp.os.386bsd.misc
Subject: Re: Shared Library Status ?
Date: 15 Mar 94 11:15:15
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 51
Message-ID: <EVERETTM.94Mar15111515@mickey.think.com>
References: <2liu8h$6k6@u.cc.utah.edu> <CONKLIN.94Mar9160535@ngai.kaleida.com>
<hastyCMGnnx.DAE@netcom.com>
<michaelv.763331698@ponderous.cc.iastate.edu>
<2lqck0$11k@pdq.coe.montana.edu>
<michaelv.763634402@ponderous.cc.iastate.edu>
NNTP-Posting-Host: mickey-fddi.think.com
In-reply-to: michaelv@iastate.edu's message of 14 Mar 94 08:40:02 GMT
In article <michaelv.763634402@ponderous.cc.iastate.edu> michaelv@iastate.edu (Michael L. VanLoon) writes:
In <2lqck0$11k@pdq.coe.montana.edu> nate@bsd.coe.montana.edu (Nate Williams) writes:
>In article <michaelv.763331698@ponderous.cc.iastate.edu>,
>Michael L. VanLoon <michaelv@iastate.edu> wrote:
>>>>Earlier this week, Intel posted an announcement of 75MHz & 100MHz
>>>>clock-tripled i486's in comp.arch. For some strange reason, Intel
>>>>calls them DX4's.
>>
>>One would hope they also increased the internal cache size. I'm sure
>>a chip like this could potentially spend a lot of time twiddling its
>>thumbs waiting on memory. However, knowing Intel, they probably
>>didn't think of this.
...
>If you have fast enough secondary cache you will still see a big performance
>increase, since the 8K cache still does a fine job of fetching ~90% of the
>instructions needed.
90% sez who? :-) 90% under DOS, maybe. I don't think a multi-tasking
OS that serves several-hundred interrupts per second and allocates
processor time between several running processes with resident memory
sets in the meg range is going to get an average 90% hit rate with an
8k cache. I'd be pleased to be proven wrong on this point, though.
Although most processors having exposed TLBs provide a "process tag" of
some sort, most of the caches I've seen don't. That means the caches must
be flushed on process context switches. So a larger cache doesn't buy you
much if you're constantly flushing before it gets nearly filled.
Even an external cache is going to be significantly slower than the
internal cache, since it will be running at one third the clock speed.
Granted, I very well may end up with one of these 486DX3 33/99 chips.
But, if it has an 8k internal cache, I firmly believe the performance
is going to be much less than three times the speed of a 486DX 33.
The internal cache on this chip is going to be much more vitally
important than any of its lower speed counterparts.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Michael L. VanLoon Iowa State University Computation Center
michaelv@iastate.edu Project Vincent Systems Staff
Free your mind and your machine -- NetBSD free Unix for PC/Mac/Amiga/etc.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
DISCLAIMER: These opinions are mine, all mine.