Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Cache Measurement
Message-ID: <12316@pt.cs.cmu.edu>
Date: 11 Mar 91 03:47:19 GMT
References: <688@spim.mips.COM>
Organization: Carnegie Mellon
Lines: 34


In article <688@spim.mips.COM> mash@mips.com (John Mashey) writes:
	[concerning benchmark results of a 68040 with and without 
	 external cache]
>4) Let's consider some reasons why that might be:
>	a) ... using page-mode DRAM ..
>	it costs you some to switch between pages.
>	b) Perhaps there is something in the 68040-interface+external
>	secondary cache control that has a higher penalty than one
>	would expect.  I assume the secondary cache is writeback (?).
>	Maybe the design requires flushing dirty data back to DRAM
>	before initiating the refill?  Maybe there are extra cycles
>	for synchronizing everything?
>Anyway, maybe somebody who actually knows can post a few details,
>since the rest of us are just guessing.

It would be really nice if mere users, such as moi, could actually
get measurements from the systems they buy.

In particular, there's no reason why cache control logic couldn't
keep some software-controlled counters. The SPUR chip had 16 such
counters, with some 5 modes. (They had to have "off", for instance,
so that they could avoid measuring the null loop.)

The cost of the above is small, as long as cache control data paths
have to exist anyway. We are, after all, in the era when chip
designers privately boast about the number of ALUs in their next
design.

So, what would we want measured?


-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon Robotics