Related articles |
---|
optimizing for caches richard@meiko.com (Richard Cownie) (1992-11-17) |
Re: optimizing for caches moss@cs.cmu.edu (1992-11-19) |
Re: optimizing for caches preston@miranda.cs.rice.edu (1992-11-19) |
Re: optimizing for caches tchannon@black.demon.co.uk (1992-11-21) |
Re: optimizing for caches markt@harlqn.co.uk (1992-11-26) |
optimizing for caches richard@meiko.com (Richard Cownie) (1992-12-01) |
Newsgroups: | comp.compilers |
From: | tchannon@black.demon.co.uk |
Organization: | Compilers Central |
Date: | Sat, 21 Nov 1992 01:20:32 GMT |
References: | 92-11-098 |
Keywords: | architecture, performance |
> So the relative cost of a cache miss has already risen from about 1.4
> instructions to > 5 instructions, and the Viking clock speed is still only
> 40MHz; the technology exists now to build processors running at 150MHz
> (e.g. Alpha), which will take the cost of a cache miss over 20
> instructions.
Ignoring the problems of very large memory arrays and other secondary
effects the access times of dy ram can with good design be rather faster
than you suggest. This is what page mode and static column mode are about.
Many accesses may be possible each with a 40ns or so cycle time and this
is quite different from the classic mode where the cycle time would be
100..120ns.
Wider data buses and possibly interleave can also help.
The trend to longer refresh times helps with being able to hold burst for
longer. I have no doubt that that are lot's of tricks I don't know about.
How close are we to being severely limited by physical size problems? (I
have in mind that a very fast systems cannot be physically large, inches
matter)
TC.
E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.