By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), May 31, 2013 4:34 am
Room: Moderated Discussions
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.
> - 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.
