home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.compilers
- Path: sparky!uunet!world!iecc!compilers-sender
- From: tchannon@black.demon.co.uk
- Subject: Re: optimizing for caches
- Reply-To: tchannon@black.demon.co.uk
- Organization: Compilers Central
- Date: Sat, 21 Nov 1992 01:20:32 GMT
- Approved: compilers@iecc.cambridge.ma.us
- Message-ID: <92-11-117@comp.compilers>
- References: <92-11-098@comp.compilers>
- Keywords: architecture, performance
- Sender: compilers-sender@iecc.cambridge.ma.us
- Lines: 27
-
- > 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
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-