On Thu, Jan 27, 2011 at 4:01 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
> >> >> I also have an implementation that performs linear search of cache sets > instead of hash table lookup. Again, I saw small improvement. But as you > mentioned, when the associativity will go up, linear search will perform > worse. Profile results showed that it takes about 100 ns for linear search > and about 125 ns for hash table lookup, associativity being 2 for the l1 > caches. May be some one should independently profile m5. That's surprising to me, but I suppose if the hash function is cheap to compute and typically hits in the first bucket then the performance could be similar. I suppose this isn't worth a lot more effort; it's certainly less significant than the double-lookup issue below. > Both icache and the dcache have the same set of states. But now that you > have mentioned it, I think it possible to do away with most of double > lookups. We maintain the invariant that caches under a single controller > maintain disjoint set of cache blocks. In this case, icache and dcache come > under the same cache controller. Currently, for an instruction fetch, we > check the dcache first. But this is obviously what we should not be doing. > Because in common case (unless of course we simulate self-modifying code > often enough), the dcache lookup will report a miss and the icache lookup is > report a hit. So, we should lookup the icache first. In case of a hit, we > know by our invariant that the dcache does not have the line. If we miss, > then we should lookup the dcache. We shoul adopt a similar strategy for > loads and stores as well. > Good point... I had forgotten the disjoint blocks invariant. It would seem like it's a total waste of time to look in any other cache than the one you expect to find it in unless there's a miss. I'd hope that's an easy fix. > We can split them under different controllers, but that would mean a lot > more work. > Yea, I wasn't suggesting that. > I will get back to you on this soon. Thanks! Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
