![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
cache size and performance
- Thread starter Coca Cola
- Start date
well, that all depends on the architechure of the proc.
but generally more cache = better.
cache is ultra fast ram used by the proc for executing instructions.
so more cache = more instructions/whatever can be stored/read without accessing main memory or hd.
but generally more cache = better.
cache is ultra fast ram used by the proc for executing instructions.
so more cache = more instructions/whatever can be stored/read without accessing main memory or hd.
Depends on the CPU design, if you are talking a Pentium 4 then yes more cache means better performance by a wide margin. Now on the Athlon side this does not hold true as much.
When Intel went from 256KB of L2 cache on the Willy P4s to the current 512KB there was a substantial increase in performance. Saying that the P4 based Celerons with only 128KB of L2 cache are just terrible and generally a much lower clocked 512KB Northwood or even a 256KB Willy has the edge over the Celeron in most benchmarks/apps.
With the Athlon the same is true but the difference is not as noticeable. Take my beloved Applebreds for example. They only have 64KB of L2 cache, compared to 256KB on the T-Bred and 512KB on the Bartons. Do I see a difference in performance between the three you may ask? Yes I do but it is not enough to warrant concern. My DC project of choice is D2OL. I ran all three AMD chips on the same identical hardware setup and found there to be only a slight loss in performance between the T-Bred and Bartons. With the Applebreds there was a larger difference but still not enough for me to be concerned. D2OL relies on pure CPU math power so your specific application may have a different outcome, but take a look at http://www.kb9skw.net/benchmark.htm if you are interested in my benchmarks.
So basically it depends on what CPU you are using (P4/Athlon) and what you are doing with said chip.
On a side note this has nothing to do with SMP and should be moved to General Hardware if/when a mod reads this.
When Intel went from 256KB of L2 cache on the Willy P4s to the current 512KB there was a substantial increase in performance. Saying that the P4 based Celerons with only 128KB of L2 cache are just terrible and generally a much lower clocked 512KB Northwood or even a 256KB Willy has the edge over the Celeron in most benchmarks/apps.
With the Athlon the same is true but the difference is not as noticeable. Take my beloved Applebreds for example. They only have 64KB of L2 cache, compared to 256KB on the T-Bred and 512KB on the Bartons. Do I see a difference in performance between the three you may ask? Yes I do but it is not enough to warrant concern. My DC project of choice is D2OL. I ran all three AMD chips on the same identical hardware setup and found there to be only a slight loss in performance between the T-Bred and Bartons. With the Applebreds there was a larger difference but still not enough for me to be concerned. D2OL relies on pure CPU math power so your specific application may have a different outcome, but take a look at http://www.kb9skw.net/benchmark.htm if you are interested in my benchmarks.
So basically it depends on what CPU you are using (P4/Athlon) and what you are doing with said chip.
On a side note this has nothing to do with SMP and should be moved to General Hardware if/when a mod reads this.
Snugglebear
[H]F Junkie
- Joined
- Apr 25, 2001
- Messages
- 11,436
The rule of thumb is whenever you double your cache size you halve the miss rate. So if you've got 256KB of cache and have a 6% miss rate, going to 512KB of cache should bring that down to 3%. Upping again to 1024KB of cache drops you down to a 1.5% miss rate. As you can see there's a problem with diminishing returns. Also consider that cache requires about 7 transistors per bit to produce, so it's a quick way of making the chip big, costly, and hot if you don't watch it. Cache also slows down the larger you make it because of address mapping overhead. Lastly, remember that miss rates are a function of how a program is coded. If you're dealing with desktop environments where the working set is small and most programs deal with tight loops, smaller caches are fine. If you're in a server environment where you're plowing through GBs of data, larger caches, even with that extra expense, are well worth it.