Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: Charles R who wrote (107325)	4/22/2000 3:14:00 AM
From: Joe NYC	Respond to of 1573088

Chuck, (and Scumbria) Re: Cache hits The answer is it depends on the application. I used to have friend who had a hobby of writing programs that thrash the cache to bring some mainframes to a crawl. How about the Sysmark 2000, which runs a multiple business apps under Windows environment? I guess running multiple applications with fairly large memory footprint would start to give you some averages. Joe

To: Charles R who wrote (107325)	4/22/2000 4:37:00 AM
From: pgerassi	Read Replies (1) \| Respond to of 1573088

Dear Charles and Jozef: Hit rates depend on three basic things: #1) Locality, Size, and Distribution of Executable. This is usually referred to as the "Working Set" of a program. #2) Size, Layout and Associatively of Cache. High Associatively increases hit rate sometimes substantially. The maximum Associatively of a given cache is equal to the number of Cache Data Lines. This type of cache is called a "Fully Associative Cache". The typical way to do this requires a that each cache data line save its address and all these addresses must be compared to the requested address. It is this last step that requires time (you want to keep this as low as you can) or parallel logic (costs you die area). CPU designers usually split the cache into a number of equal sizes called sets. The Number of Sets is usually a power of 2. Each set is to cache a subsection of memory equal to the Amount of Memory divided by the Number of Sets. This reduces the Data Address by a number of bits equal to the log base 2 of the Number of Sets. The address bits to keep are all the high order bits which causes a "Hashing" of the areas cached by a set. The number of data lines in a set is the Number of Ways of the cache. Thus a 6 Way Cache has six data lines per set. This reduces the logic to compare the addresses of a set by substantial amounts. "Direct Mapped" just means a 1 Way Cache. I have always felt that a Fully Associative Cache is the way we are heading but the Data Cache Lines probably have to get bigger. The larger cache lines have the penalty of taking longer to fill. This is what will ultimately cause packetizing memory transfers. If the working set is to large for the cache, you get thrashing which makes the CPU perform worse than having no cache at all. This gets us to point three. #3) The Cache Miss Update Strategy. How a miss is handled also has a bearing. You can go from a no update the cache on miss (suggested when thrashing occurs) to a LRU, Least Recently Used, update strategy used in most caches that have a high ratio between the speed of the Cache divided by the speed of what is being cached like a Disk Cache. A LFU Fully Associative 64K Data Cache will have a higher Average Hit Rate than a Simple Replacement Direct Mapped 512K Data Cache when dealing with Programs having a Working Set of 1M or more. It will also take less die area. This is where I think that most current designers are falling down. I hope this educates you about the difficulties in estimating hit rates and where simplification can lead to incorrect solutions. Pete