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!msuinfo!agate!howland.reston.ans.net!pipex!sunic!EU.net!chsun!hslrswi!aut!nbladt From: nbladt@autelca.ascom.ch (Norbert Bladt) Subject: Re: Shared Library Status ? Message-ID: <CMn8G1.MA4@autelca.ascom.ch> Organization: Ascom Autelca AG, Guemligen, Switzerland 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> Date: Mon, 14 Mar 1994 07:21:36 GMT Lines: 29 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. That's why Intel increases the size of the cache to 16kB ?! Norbert. -- Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland Phone: +41 31 999 65 52 FAX: +41 31 999 65 44 Mail: nbladt@autelca.ascom.ch UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt