Re: optimizing for caches

tchannon@black.demon.co.uk
Sat, 21 Nov 1992 01:20:32 GMT

          From comp.compilers

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)
| List of all articles for this month |
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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.