cache question

quote:

---

cache lines are 32 bytes in length and alignment, right?

---

No. First off I think it varies from processor to processor. I know that newer Pentium Xeons for instance have 128 byte cache lines.

quote:

---

no prospect of increasing this size?

---

I think it would be very foolish to assume that there is no prospect for increasing the size of the cache lines.

Let the compiler worry about these kinds of things.

It depends highly on the processor. Where did you get this magic number 32?

Athlon: 64; P4: 128; any other Intel / AMD: 32. (not sure about VIA, Transmeta)

> Let the compiler worry about these kinds of things.
I have yet to see the compiler that a) knows the target platform''s cache line size b) does something with this information. It is also something useful to know.

There''s nothing holy about the cache line size: you want a compromise between latency (takes 1 cycle/word in burst phase) and bandwidth (sending the address is slow, ''cause row/col addr lines are muxed, and the controller''s clocked much slower than the CPU, so you want to amortize this cost by grabbing a chunk of data). The size of this chunk (''burst length'') is programmable, but wouldn''t do you a lot of good to do so without changing the CPU''s cache
You don''t want it too high, in case the app doesn''t have linear access patterns (i.e. code that jumps around a bunch, or AOS data). Just so happens that in non-DDR systems, 4x8 bytes is a good balance.

My point was, let the compiler worry about optimizations. If you are doing something complex enough to have a need to know the cache line length to get an extra performance boost, I''d think you''d already know how big the cache lines are, since you''d probably keep up with such things if you were that much of a performance guru.

The only instance I have ever seen where the cache line length was taken into consideration was an SMP chess program that got poor performance on a particular cpu. It had to do with the size of one of the commonly used internal structures, and the multiple threads were invalidating each other''s cache lines, forcing them to read them from memory which is slower (at least that was the theory).

Oh really?

If I have large-ish structures (32 or 64 bytes), it makes sense to fit them neatly on a cache line.

If I align a few of these to 32 but the cache is 128, i might be wasting half a cache line or more. This could easily double or treble the access time.

It's not a low-level piece of trickery, it boils down to this:

__asm{align CACHE_SIZE}
BigStructure MyData[10]




PS I've been relying on 32-byte cache lines for a while, it's the number quoted in many reference texts. It recently occured to me memory is speeding up with faster motherboards, so this might give room for bigger cache lines.
I think keeping cache lines small is sensible (except in the code cache). Reading 2*32 lines is going to be about as slow as 1*64, and there's less chance of wasteage.

********


A Problem Worthy of Attack
Proves It's Worth by Fighting Back

[edited by - walkingcarcass on April 26, 2003 5:28:55 AM]

Russell: you can mess up performance with anything (and the cache line issue isn''t hard to fix, as walkingcarcass shows). The compiler can''t do anything about this problem.
It doesn''t help to say "if you''re a guru, you know this already"

As for memory getting faster, you have DDR (2 ops / cycle), and that''s about it.
Part of the reason we have a cache is that reading 2*32 is much slower than 1*64!

quote:

---

[a bit of context: all the delays between starting the read and burst begin]
1) RAS precharge (tRP) - clear data lines and recharge caps (unloaded after bank activate)
2) RAS to CAS delay (tRCD) - pause after sending row address and before column address (why? sense amps need to stabilize)
3) CAS latency (tCL) - delay until data ready, after CA sent

---

Let’s call that 7 cycles on average (- for page hit or bank closed, + for miss and bank open). The actual data transfer runs at 2 words / cycle, so 2*32 takes >= 18 cycles (alright, maybe a bit less, ''cause the next address can be sent during the burst), and 1*64 >= 11 cycles.

quote:

---

Original post by Jan Wassenberg
As for memory getting faster, you have DDR (2 ops / cycle), and that''s about it.

---

That depends totally on your application. Programs that make a lot of memory accesses will probably benefit from using SDRAM. Fewer memory accesses and DDR or Rambus will be better.

My statement was badly put. I was talking about expected advances in memory speed; the last big change was DDR-266. You can pump up the FSB (DDR-333), but that seems a while off.
Let''s see what the hardware guys pull out of their as^H^Hhat next

That aside, I don''t see how DDR can be slower than normal SDRAM (even with longer burst). What do you mean?

It was brought up in a chess programming forum. Any good chess program will use a huge hash table (usually 64-256MB). Someone did some tests using SDRAM and DDR, and SDRAM was faster because it had a lower latency I think.

I''ve never understood how it can be hard to have eg a 64Mb L2 cache, or simply build memory which runs of a multiplier in the same way a processor does. Maybe I''m just ignorant, then again, maybe the boffins are just taking their time so as to keep their jobs...

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

> Someone did some tests using SDRAM and DDR, and SDRAM was faster because it had a lower latency I think. <
I assume the test was fair (they''d have to have a dual mem mobo, BIOS timings were ok, etc.). The command latency is the only way it could be faster, but my DDR mem has tCL = 2 (don''t know of any SDRAM better than 2/2/2).

walkingcarcass: time for hardware class
1) SRAM is expensive
2) clock is limited by design of the memory - it''s an array of zillions (order 10^8) of transistors. You can''t propagate the signal fast enough.

@walkingcarcass:

Sandpile knows