Ricardo B (ricardo.b.delete@this.xxxxx.xx) on May 31, 2013 4:34 am wrote:
> Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 30, 2013 7:52 pm wrote:
> > - Ah, yes, your explanation of writes going down the memory
> > hierarchy makes more sense than going up from the
> > bottom. Definitely makes more sense to keep something that
> > may be used soon in the L1 data cache rather than
> > all the way in RAM. Say, does the Store Buffer handle this eviction as well, or is it something else?
>
> It's the caches themselves who handle evictions, using a cache line granularity (64B in most CPUs)
> The store buffer is used to hold stores until they can be committed to the L1 D$.
>
> >
> > - Oh, that complicates my understanding of the AGU... Why would
> > the virtual address need to be kept in a mathematical
> > equation at all? Wouldn't it be much simpler to simply keep them
> > all organized by number? Or is there some applications
> > that operate off doing math with virtual addresses? I cant imagine any personally...
>
> Virtual addresses *are* numbers (and so are physical addresses).
> But to arrive at the number you want, you often need to do some trivial math operations.
>
> Ie, if you have an array of 4-byte elements and you want to read the nth element, then the (virtual)
> address you want to read is given by the following expression: array_starting_address + 4*n.
>
> If you have "array_starting_address" in register EAX and
> "n" in register ESI, then you need to do EAX + 4*ESI.
>
> That's what an AGU is: a simplified ALU, which supports typical
> math operations involved in address calculations.
>
> And in x86, you can use that expression as a instruction operand and let the AGU
> do the math, instead of using multiple instructions to do the math first.
>
>
> > - So virtual addresses are basically used to keep everything
> > organized and in it's own space of memory? Is the
> > benefit caused by the organization worth the extra clks it takes to generate and use the virtual address?
>
> Assuming you don't want to go back to a world where one misbehaved application
> crashes your entire system, I'd say it's damn well worth it.
> Or a world where an application fails because it can't find a big contiguous chunk
> of addresses to fit an array, although you have plenty of physical free memory.
>
> Without the virtual/physical address translation, operative systems would still be back at the level of DOS.
>
> > - So to my understanding, HyperThreading simply allows one program to use the core primarily,
> > but also allows another program to "mooch" off unused execution units? If this is the case, how
>
> In Intel CPUs, both program/threads have the same priority.
>
> > come games don't get a big boost from HyperThreading? Is it because all their calculations are
> > primarily ALU anyways, so even adding HT will simply keep the unused FP units unused?
>
> Most games aren't multi-threaded, period. Many of the ones who are see a benefit with HT.
> Some types of applications which make good use of the ALUs and etc
> do see a worsening of performance when HT is enabled though.
>
>

As usual, another quality post from you!

- Ah, okay I understand the evictions now. Thank you.

- Oh, now I understand as to why virtual addresses can be held in mathematical equations. The array example definitely helped. Though one more about AGU's; say a AGU is given an instruction to calculate the virtual address of (array+4), and it does so successfully. Where would the result of the virtual address be stored, and how would it be used?

- Mmm... Though what would be an example of a "misbehaving" application? (besides the obvious malicious software; but that is designed to "misbehave", so in a way that wouldnt exactly count) And also, why would a program need "virtual contiguous memory" if the physical addresses are not contiguous anyways?

- Sorry, I still don't quite understand how multi-threading works. If there are two programs, one of each using one thread, how does a single execution unit perform as two?

Thanks for all your help as always!