Question abt size of L2 Cache

I went to a local electronics superstore and asked about laptops. We talked abt difference btw cpus and the sales guy said that the size of the L2 cache for the T7000 series matters a lot. As we compared a Compaq with T7500 with 4mb L2 cache and a NEC T7250 with 2mb L2 cache. The price was identical, specs wise, the only key difference was that the Compaq came with Intel X3100 Gfx card 128 dedicated ram and the NEC with a 8600GS 256 dedicated ram.

So I asked is there any difference in gaming performance? He said the smaller L2 cache on the T7250 will handicap the 8600GS gpu, so the Compaq with T7500 and X3100 will actually perform better.

So is the above claim true? does the size of L2 cache matters so much? in this case the T7500 has double the size. I always thought Games rely more on the GPU and gfx memory than the cache. I would appreciate if someone could help me clear my doubts.

thanks

 

I really doubt the T7250 will cripple the 8600GS. There is no way the X3100 would perform better than the 8600GS.
Cache does matter, but not a great deal from the tests I have seen.

 

The NEC with the 8600GS would most definitely preform better in games than the X3100 even with the different levels in L2 cache.

 

I have a T7250 in my zepto and I get the same gaming performance with other laptops that have the T7300. The only difference between the two processors is the 2mb of cache.

I get around 3250 in 3d mark 06 with a 8600M GT which is the same as most are getting with T7300, I doubt anyone could tell the difference in normal gaming.

I think the 8600M GT in my laptop is the bottleneck for games (most) and not the processor. Go for the laptop with the better graphics card if you are concerned about games.

 

ah, thanks for the replies. So my next questions are:

1. I will be using Autocad for my work, will the extra cache make a difference?

2. In what situations will the extra 2mb cache on the T7500 matter?

 

There's no way in hell that 2mb of cpu cache will make a crappy IGP perform better than an 8600gt.

While in cpu intensive tasks the extra speed and cache will show a small difference, in games it will not matter, especially comparing an integrated intel gpu vs a high end 8600gt.

 

It's tricky to measure, because the cache isn't a separate feature than an application can choose whether or not to use

Basically, the CPU simply puts the most recently used data in the cache. So obviously, for data that works primarily on, say, 2MB of data, there's nothing to be gained by having a bigger cache. For data that works on 500MB of data? It depends on the access patterns. Does it access smaller group of this at a time? If so, the cache helps a lot. If it just reads through all 500MB of data from start to finish, the cache won't make a difference.

For games, the GPU is always the primary bottleneck. As far as the cache goes, don't think about that in isolation, look at the CPU as a whole. Just like you don't wonder whether a 16 or 18-stage pipeline is better, or what cache associativity is fastest. The cache is just part of the CPU.
A not very scientific rule of thumb (I just made it up) is that each time the cache size doubles, you can add 10% CPU performance.

But it depends a lot on the application.

 

sorry Jalf, I don't quite understand ur explanation. For autocad basically, the file size ranges, depending on how big the drawing is. Atm i have file size up to approx 5 mb. I do a lot of saving, like 4 times in an hr? or more. So to my knowledge of cpu cache, yes the cpu should be accessing the cache pretty often, although i can be completely wrong abt this. From what I know, the cache stores the recently most accessed data. So when u retrieve that data again, the cpu goes to the cache and not to the hdd. I'm not entirely sure how autocad interacts with the cache or whether it stores stuff there...

but i do hope the core 2 duo and faster ram gives me a significant improvement! as far as i know, autocad does hog the cpu and ram from time to time!

 

Exactly my point.
It's just a part of the CPU, and to understand it, you really need to understand how CPU's work. Which is more than I expect of most people.
My point is that you should just treat it like all the other bits of a CPU you don't know about (length of the pipeline, type of branch predictor, cache associativity, exclusive/inclusive cache, number of ALU's and so on)
It's just something the CPU uses internally, but applications don't "make use" of it, and aren't really aware of it. And you can't look at it in isolation and predict how it affects performance.

Saving isn't really relevant, since that's harddisk access. The cache saves your CPU from having to do memory (RAM) accesses.
And the timescale is far different. A failure to find data in cache might delay an application for 100 nanoseconds, or 0.1 microsecond. Obviously, it has to happen pretty often to have any impact at all.
You also can't necessarily assume the filesize to be meaningful. These are typically compressed in various ways, while when the data is in memory, all sorts of helper data has to be constructed as well, so it might take up far more memory.

But for the sake of example, imagine that you're working on 10MB of data, and let's assume your CPU has 4MB of cache.
Application A simply reads through this data from start to end, repeatedly. It starts at byte 0, reads all the way to byte 10,000,000 (roughly), and then starts over.
That won't benefit from the cache at all. For the first 4 million bytes, the CPU will write them into its cache as it encounters them, in the hope that they'll still be there the next time we need them. Then, after the first 4MB, we're out of cache, so we have to start overwriting existing entries. After 8MB, all the original 4MB are completely gone from the cache. Now after we've read the remaining 2MB of data, we start over, and... all the data we read before is gone from the cache, so we have to read it from RAM again, which is just as slow as the first time.

Now let's say that application B focuses on one small part of the data at a time. First, it does a lot of processing on the first few MB, where this data will quickly be loaded into the cache, where it remains for the rest of this processing, speeding things up greatly.
Then it moves on to the next few MB, which gets loaded into cache, and processed for a while, again benefiting from working on data that's already in the cache.

Application B would be far faster than A then, simply because it's more cache-friendly.

The point of all this? Simply that it's not easy to say how much a given application will benefit from a larger cache. It depends on exactly what the application does, as well as the order in which it does it. And often, even the programmers who made the application aren't too sure on how cache-friendly their app is, so even they can't give you a good answer.

As I said, assume that you'll gain 10% performance by doubling the cache. It's not an accurate rule, it won't stand up to benchmarks, but it gives you a rough ballpark figure of what to expect from a bigger cache.
But in some applications, a larger cache might give you 50% or more extra performance. In others, it might make no difference at all.

 

One of the sights I think Antech, maybe Tomshardware did a comparison and in what they determined were CPU intensive benchmarks found approximately a 10% improvement in CPU performance with 4MB vs 2mb L2. So I speculate that real world non boutique type benchmarks but real world the 10% and less # to be more accurate then 50%. 50% is more likely to be seen in synthetic benchmark that utilizes >2MB and <=4MB.

For gaming and most situations I would go with 7250+8600GS. AutoCad is not going to go beyound 7250 ability to function well.

 

ah ic. Jeff, Thanks for detailed explanation.

I'm going to go down to another place to check out laptops, maybe they would have 4mb cache with 8600GS and not at a premium! brand names to me are notorious for bumping up prices just when some extra "exclusive" component is included