Author: Peter Fendrich
Date: 02:14:45 09/26/01
Go up one level in this thread
On September 25, 2001 at 17:41:49, Robert Hyatt wrote: >On September 25, 2001 at 16:34:18, Peter Fendrich wrote: > >>I've never cared about optimizing at or near hw level but maybe I at least >>should think about it... >> >>What's all this about the cashline? > > >First, it is "cache" not "cash". Ok, we might need some of both... :-) >>What is put in the cash when *p = *q; > >The 32 bytes around p will be loaded, the 32 bytes around q will be loaded. >Then the 32 bytes around the address contained in q will be loaded, and finally >the 32 bytes around the address contained in p will be loaded. If P, q, and >the things they point to are all in the same 32 byte 'block' of memory >(memory is blocked, with the first 32 bytes in block 0, the next 32 bytes in >block 1, throughout memory this continues) then just that one 32 byte block of >memory will be loaded, which will be 4x faster. > > > > >>The pointers (both?) or the data they point at? > >All of the above. Plus everything within each 32 byte block you referenced >either with a pointer or the address in the pointer. > > >>or when *p == *q; The same as above? > > >same. > > > >>or when p[x] = p[y]; Is x and y put there? > >x and y plus the 32 bytes around p[x] and p[y]. > > >> >>Will it give any significant savings to care about these things? > >yes it will.. > >>//Peter So then it will be filled up in this way up to 256K and then overwritten with a FIFO scheme or will frequently accessed blocks in some magical way stay longer? Is it always "aligned" 32-byte blocks - will a pointer to a big struct cause a 32-byte block to be loaded as well? The first simple implication must be to keep and access data together of course. Another one must be how to design multidimensional tables so they are not accessed in a fragmented manner. Aligning struct data important? Something else? //Peter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.