On Fri, Sep 23, 2011 at 04:22:09PM +0100, Greg Stark wrote: > So you have two memory fetches which I guess I still imagine have to > be initiated in the right order but they're both in flight at the same > time. I have no idea how the memory controller works and I could > easily imagine either one grabbing the value before the other.
That's easy. If one is in cache and the other isn't then the results will come back out of order. > I'm not even clear how other processors can reasonably avoid this. It > must be fantastically expensive to keep track of which branch > predictions depended on which registers and which memory fetches the > value of those registers depended on. And then it would have to > somehow inform the memory controller of those old memory fetches that > this new memory fetch is dependent on and have it ensure that the > fetches are read the right order? I think memory accesses are also fantastically expensive, so it's worth some effort to optimise that. I found the Linux kernel document on this topic quite readable. I think the main lesson here is that processors track data dependancies (other than the Alpha apparently), but not control dependancies. So in the example, the value of i is dependant on num_items, but not via any calculation. IThat control dependancies are not tracked makes some sense, since branches depend on flags bit, and just about any calculation changes the flag bits, but most of the time these changes are not used. It also not a question of the knowing the address either, since the first load, if any, will be *q->items, irrespective of the precise value of num_items. This address may be calculated long in advance. Have a nice day, -- Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
signature.asc
Description: Digital signature
