Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!ihnp4.ucsd.edu!swrinde!elroy.jpl.nasa.gov!decwrl!usenet.coe.montana.edu!bsd.coe.montana.edu!nate From: nate@bsd.coe.montana.edu (Nate Williams) Newsgroups: comp.os.386bsd.misc Subject: Re: Shared Library Status ? Date: 11 Mar 1994 18:17:36 GMT Organization: Montana State University, Bozeman MT Lines: 28 Message-ID: <2lqck0$11k@pdq.coe.montana.edu> References: <2liu8h$6k6@u.cc.utah.edu> <CONKLIN.94Mar9160535@ngai.kaleida.com> <hastyCMGnnx.DAE@netcom.com> <michaelv.763331698@ponderous.cc.iastate.edu> NNTP-Posting-Host: bsd.coe.montana.edu 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 -- nate@bsd.coe.montana.edu | FreeBSD core member and all around tech. nate@cs.montana.edu | weenie. work #: (406) 994-4836 | Graduating May '94 with a BS in EE home #: (406) 586-0579 | - looking for work in CS/EE field.