By: Klimax (danklima.delete@this.gmail.com), May 31, 2013 7:15 am
Room: Moderated Discussions
Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 31, 2013 6:59 am wrote:
> 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.
> >
> >
...
> - 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?
..
Simple example: Due to bug (like unchecked end of array) it will write past allocated range. (Or just randomly all over memory) And in process it will destroy whatever it can including kernel structure.
For crazy reading about crazy programs I recommend http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf
Bonus chapter for book "The Old New Thing" by Raymond Chen.
As for contiguous memory - arrays. (Enables simple and fast way to access any element while knowing only starting address and size of structure)
> 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.
> >
> >
...
> - 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?
..
Simple example: Due to bug (like unchecked end of array) it will write past allocated range. (Or just randomly all over memory) And in process it will destroy whatever it can including kernel structure.
For crazy reading about crazy programs I recommend http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf
Bonus chapter for book "The Old New Thing" by Raymond Chen.
As for contiguous memory - arrays. (Enables simple and fast way to access any element while knowing only starting address and size of structure)