Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna.cs.rmit.oz.au!aggedor.rmit.EDU.AU!harbinger.cc.monash.edu.au!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!gokings From: gokings@netcom.com (Russell Marrash) Subject: Re: Shared Library Status ? Message-ID: <gokingsCMLLsD.3K9@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <hastyCMGnnx.DAE@netcom.com> <michaelv.763331698@ponderous.cc.iastate.edu> <2lqck0$11k@pdq.coe.montana.edu> Date: Sun, 13 Mar 1994 10:14:37 GMT Lines: 33 In article <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. > >C'mon Michael, what experience do you have developing chips? On-board >cache takes up a *huge* chunk of the available space on the chip. >Increasing it would mean losing the FPU processor at least (which is >what IBM did to get the speed out of their Blue Lightning). > >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. > > >Nate There is also a point where the amount of cache you add no longer gives you a price vs performance edge. I work for a company that developes mainframe computers, this is a big consideration in the design of the processor board for the system we design. Just my .02 worth. Russell Marrash gokings@netcom.com