Expertiza_Wiki - User contributions [en]

CSC 456 Fall 2013/4b cv

2013-11-22T08:07:45Z

Bvuong:

Non-Uniform Memory Access(NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. NUMA is a very important processor feature and if it is ignored one can expect sub-par application memory performance.

===Background===

NUMA is often grouped together with Uniform Memory Access(UMA) because the two methods of memory management have similar features. The architecture of UMA(see figure 1.1)<ref name="ott11">David Ott. Optimizing Applications for NUMA. http://software.intel.com/en-us/articles/optimizing-applications-for-numa
{{cite web
| url = http://software.intel.com/en-us/articles/optimizing-applications-for-numa
| title = Optimizing Applications for NUMA
| last1 = Ott
| first1 = David
| location = Intel
| date = November 02, 2011
| accessdate = November 18, 2013
| separator = ,
}}
</ref>has a bus inbetween the processors/cache and the memory for each processor. NUMA(see figure 1.2)<ref name = "ott11"/> however has a directl connection between the processor/cache and the memory for the processor, the bus is then connected to the memory. The main trade off between UMA and NUMA is related to memory access time. Since the NUMA memory is directly linked to the processor/cache it provides faster access to local data but is slower when accessing remote data<ref name = "ott11"/>.

[[File:UMA.jpg|center]]
<div style="text-align:center">'''Figure 1.1 Diagram of the UMA memory configuration'''</div>
[[File:NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.2 Diagram of the NUMA memory configuration'''</div>

The NUMA system memory is managed in a node based model(see figure 1.3)<ref name = "ott11"/>. This design implements a mixture of UMA and NUMA by creating a node at encompasses a NUMA system and connects the nodes so the entire architecture resembles the UMA system.

[[File:UMA&NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.3 Diagram of the mixture of the UMA and NUMA memory configurations'''</div>

====Issues with NUMA====
As previously stated one of the advantages from using the NUMA system is the fast local memory access due to the location of the memory in relation to the processor/cache. This is also a disadvantage, when comparing NUMA to UMA, when a thread tries to access memory not located locally. NUMA is slower and less efficient about obtaining the non-localized data from memory but this can be solved in two different ways<ref name = "ott11"/>.

The first method of improving the performance of NUMA is using processor affinity<ref name ="ott11"/>. Processor affinity can be used when multiple threads are running on different processors. In order to reduce the amount of overhead from running these different threads processor affinity is used to manage them. Processor affinity is the practice of assigning threads that correspond with a certain application to certain cores because of the memory they are locally storing<ref name = "ott11"/>. This is designed the decrease the amount of memory requests that are not within the local memory. However this practice can also cause issues because it does not balance the work evenly so the resources can be under or over utilized<ref name ="ott11"/>. The second way of improving the performance of NUMA memory management is by using different page allocation strategies to utilize the local memory in more efficient ways.

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:<ref name="fasdf">http://www.sciencedirect.com/science/article/pii/074373159190117R</ref>
* Fetch - determining which page to be brought to main memory
** demand fetching
** prefetching
* Placement - determining where to hold the page
** Fixed-Node
** Preferred-Node
** Random-Node
* Replacement - determining which page to remove for new pages
** Per-Task
** Per-Computation
** Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* random -

===Page Allocation Support in OpenMP===
* has directives for allocating blocks a certain way (concerning NUMA)
** <code>!dec$ migrate_next_touch(v1,...,v2)</code> - migrates selected pages to referencing thread for easy access<ref name="craig00">http://www.sc2000.org/techpapr/papers/pap.pap226.pdf</ref>
** <code>!dec$ memories</code> - interprets memories of a machine to be seen as an array
** <code>!dec$ template</code> - defines virtual array

===References===
<ref name="lee96">JongWoo Lee and Yookun Cho. An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors. https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
{{cite web
| url = https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
| title = An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors
| last1 = Lee
| first1 = JongWoo
| last2 = Cho
| first2 = Yookun
| location = Korea
| date = 1996
| accessdate = November 19, 2013
| separator = ,
}}
</ref>
<references/>

CSC 456 Fall 2013/4b cv

2013-11-22T08:06:27Z

Bvuong: /* Page Allocation Support in OpenMP */

Non-Uniform Memory Access(NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. NUMA is a very important processor feature and if it is ignored one can expect sub-par application memory performance.

===Background===

NUMA is often grouped together with Uniform Memory Access(UMA) because the two methods of memory management have similar features. The architecture of UMA(see figure 1.1)<ref name="ott11">David Ott. Optimizing Applications for NUMA. http://software.intel.com/en-us/articles/optimizing-applications-for-numa
{{cite web
| url = http://software.intel.com/en-us/articles/optimizing-applications-for-numa
| title = Optimizing Applications for NUMA
| last1 = Ott
| first1 = David
| location = Intel
| date = November 02, 2011
| accessdate = November 18, 2013
| separator = ,
}}
</ref>has a bus inbetween the processors/cache and the memory for each processor. NUMA(see figure 1.2)<ref name = "ott11"/> however has a directl connection between the processor/cache and the memory for the processor, the bus is then connected to the memory. The main trade off between UMA and NUMA is related to memory access time. Since the NUMA memory is directly linked to the processor/cache it provides faster access to local data but is slower when accessing remote data<ref name = "ott11"/>.

[[File:UMA.jpg|center]]
<div style="text-align:center">'''Figure 1.1 Diagram of the UMA memory configuration'''</div>
[[File:NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.2 Diagram of the NUMA memory configuration'''</div>

The NUMA system memory is managed in a node based model(see figure 1.3)<ref name = "ott11"/>. This design implements a mixture of UMA and NUMA by creating a node at encompasses a NUMA system and connects the nodes so the entire architecture resembles the UMA system.

[[File:UMA&NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.3 Diagram of the mixture of the UMA and NUMA memory configurations'''</div>

====Issues with NUMA====
As previously stated one of the advantages from using the NUMA system is the fast local memory access due to the location of the memory in relation to the processor/cache. This is also a disadvantage, when comparing NUMA to UMA, when a thread tries to access memory not located locally. NUMA is slower and less efficient about obtaining the non-localized data from memory but this can be solved in two different ways<ref name = "ott11"/>.

The first method of improving the performance of NUMA is using processor affinity<ref name ="ott11"/>. Processor affinity can be used when multiple threads are running on different processors. In order to reduce the amount of overhead from running these different threads processor affinity is used to manage them. Processor affinity is the practice of assigning threads that correspond with a certain application to certain cores because of the memory they are locally storing<ref name = "ott11"/>. This is designed the decrease the amount of memory requests that are not within the local memory. However this practice can also cause issues because it does not balance the work evenly so the resources can be under or over utilized<ref name ="ott11"/>. The second way of improving the performance of NUMA memory management is by using different page allocation strategies to utilize the local memory in more efficient ways.

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
** demand fetching
** prefetching
* Placement - determining where to hold the page
** Fixed-Node
** Preferred-Node
** Random-Node
* Replacement - determining which page to remove for new pages
** Per-Task
** Per-Computation
** Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* random -

===Page Allocation Support in OpenMP===
* has directives for allocating blocks a certain way (concerning NUMA)
** <code>!dec$ migrate_next_touch(v1,...,v2)</code> - migrates selected pages to referencing thread for easy access<ref name="craig00">http://www.sc2000.org/techpapr/papers/pap.pap226.pdf</ref>
** <code>!dec$ memories</code> - interprets memories of a machine to be seen as an array
** <code>!dec$ template</code> - defines virtual array

===References===
<ref name="lee96">JongWoo Lee and Yookun Cho. An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors. https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
{{cite web
| url = https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
| title = An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors
| last1 = Lee
| first1 = JongWoo
| last2 = Cho
| first2 = Yookun
| location = Korea
| date = 1996
| accessdate = November 19, 2013
| separator = ,
}}
</ref>
<references/>

CSC 456 Fall 2013/4b cv

2013-11-22T07:10:16Z

Bvuong:

Non-Uniform Memory Access(NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. NUMA is a very important processor feature and if it is ignored one can expect sub-par application memory performance.

===Background===

NUMA is often grouped together with Uniform Memory Access(UMA) because the two methods of memory management have similar features. The architecture of UMA(see figure 1.1)<ref name="ott11">David Ott. Optimizing Applications for NUMA. http://software.intel.com/en-us/articles/optimizing-applications-for-numa
{{cite web
| url = http://software.intel.com/en-us/articles/optimizing-applications-for-numa
| title = Optimizing Applications for NUMA
| last1 = Ott
| first1 = David
| location = Intel
| date = November 02, 2011
| accessdate = November 18, 2013
| separator = ,
}}
</ref>has a bus inbetween the processors/cache and the memory for each processor. NUMA(see figure 1.2)<ref name = "ott11"/> however has a directl connection between the processor/cache and the memory for the processor, the bus is then connected to the memory. The main trade off between UMA and NUMA is related to memory access time. Since the NUMA memory is directly linked to the processor/cache it provides faster access to local data but is slower when accessing remote data<ref name = "ott11"/>.

[[File:UMA.jpg|center]]
<div style="text-align:center">'''Figure 1.1 Diagram of the UMA memory configuration'''</div>
[[File:NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.2 Diagram of the NUMA memory configuration'''</div>

The NUMA system memory is managed in a node based model(see figure 1.3)<ref name = "ott11"/>. This design implements a mixture of UMA and NUMA by creating a node at encompasses a NUMA system and connects the nodes so the entire architecture resembles the UMA system.

[[File:UMA&NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.3 Diagram of the mixture of the UMA and NUMA memory configurations'''</div>

====Issues with NUMA====
As previously stated one of the advantages from using the NUMA system is the fast local memory access due to the location of the memory in relation to the processor/cache. This is also a disadvantage, when comparing NUMA to UMA, when a thread tries to access memory not located locally. NUMA is slower and less efficient about obtaining the non-localized data from memory but this can be solved in two different ways<ref name = "ott11"/>.

The first method of improving the performance of NUMA is using processor affinity<ref name ="ott11"/>. Processor affinity can be used when multiple threads are running on different processors. In order to reduce the amount of overhead from running these different threads processor affinity is used to manage them. Processor affinity is the practice of assigning threads that correspond with a certain application to certain cores because of the memory they are locally storing<ref name = "ott11"/>. This is designed the decrease the amount of memory requests that are not within the local memory. However this practice can also cause issues because it does not balance the work evenly so the resources can be under or over utilized<ref name ="ott11"/>. The second way of improving the performance of NUMA memory management is by using different page allocation strategies to utilize the local memory in more efficient ways.

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
** demand fetching
** prefetching
* Placement - determining where to hold the page
** Fixed-Node
** Preferred-Node
** Random-Node
* Replacement - determining which page to remove for new pages
** Per-Task
** Per-Computation
** Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* random -

===Page Allocation Support in OpenMP===
* has directives for allocating blocks a certain way
** !dec$ migrate_next_touch(v1,...,v2) - migrates selected pages to referencing thread for easy access<ref name="craig00">http://www.sc2000.org/techpapr/papers/pap.pap226.pdf</ref>

===References===
<ref name="lee96">JongWoo Lee and Yookun Cho. An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors. https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
{{cite web
| url = https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
| title = An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors
| last1 = Lee
| first1 = JongWoo
| last2 = Cho
| first2 = Yookun
| location = Korea
| date = 1996
| accessdate = November 19, 2013
| separator = ,
}}
</ref>
<references/>

CSC 456 Fall 2013/4b cv

2013-11-22T06:48:03Z

Bvuong:

Non-Uniform Memory Access(NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. NUMA is a very important processor feature and if it is ignored one can expect sub-par application memory performance.

===Background===

NUMA is often grouped together with Uniform Memory Access(UMA) because the two methods of memory management have similar features. The architecture of UMA(see figure 1.1)<ref name="ott11">David Ott. Optimizing Applications for NUMA. http://software.intel.com/en-us/articles/optimizing-applications-for-numa
{{cite web
| url = http://software.intel.com/en-us/articles/optimizing-applications-for-numa
| title = Optimizing Applications for NUMA
| last1 = Ott
| first1 = David
| location = Intel
| date = November 02, 2011
| accessdate = November 18, 2013
| separator = ,
}}
</ref>has a bus inbetween the processors/cache and the memory for each processor. NUMA(see figure 1.2)<ref name = "ott11"/> however has a directl connection between the processor/cache and the memory for the processor, the bus is then connected to the memory. The main trade off between UMA and NUMA is related to memory access time. Since the NUMA memory is directly linked to the processor/cache it provides faster access to local data but is slower when accessing remote data<ref name = "ott11"/>.

[[File:UMA.jpg|center]]
<div style="text-align:center">'''Figure 1.1 Diagram of the UMA memory configuration'''</div>
[[File:NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.2 Diagram of the NUMA memory configuration'''</div>

The NUMA system memory is managed in a node based model(see figure 1.3)<ref name = "ott11"/>. This design implements a mixture of UMA and NUMA by creating a node at encompasses a NUMA system and connects the nodes so the entire architecture resembles the UMA system.

[[File:UMA&NUMA.jpg|center]]
<div style="text-align:center">'''Figure 1.3 Diagram of the mixture of the UMA and NUMA memory configurations'''</div>

====Issues with NUMA====
As previously stated one of the advantages from using the NUMA system is the fast local memory access due to the location of the memory in relation to the processor/cache. This is also a disadvantage, when comparing NUMA to UMA, when a thread tries to access memory not located locally. NUMA is slower and less efficient about obtaining the non-localized data from memory but this can be solved in two different ways<ref name = "ott11"/>.

The first method of improving the performance of NUMA is using processor affinity<ref name ="ott11"/>. Processor affinity can be used when multiple threads are running on different processors. In order to reduce the amount of overhead from running these different threads processor affinity is used to manage them. Processor affinity is the practice of assigning threads that correspond with a certain application to certain cores because of the memory they are locally storing<ref name = "ott11"/>. This is designed the decrease the amount of memory requests that are not within the local memory. However this practice can also cause issues because it does not balance the work evenly so the resources can be under or over utilized<ref name ="ott11"/>. The second way of improving the performance of NUMA memory management is by using different page allocation strategies to utilize the local memory in more efficient ways.

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
** demand fetching
** prefetching
* Placement - determining where to hold the page
** Fixed-Node
** Preferred-Node
** Random-Node
* Replacement - determining which page to remove for new pages
** Per-Task
** Per-Computation
** Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* random -

===Page Allocation Support in OpenMP===
* has directives for allocating blocks a certain way
** !dec$ migrate_next_touch(v1,...,v2) - migrates selected pages to referencing thread for easy access<ref name="craig00">http://www.sc2000.org/techpapr/papers/pap.pap226.pdf</ref>

<ref name="lee96">JongWoo Lee and Yookun Cho. An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors. https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
{{cite web
| url = https://parasol.tamu.edu/~rwerger/Courses/689/spring2002/day-3-ParMemAlloc/papers/lee96effective.pdf
| title = An Effective Shared Memory Allocator for Reducing False Sharing in NUMA Processors
| last1 = Lee
| first1 = JongWoo
| last2 = Cho
| first2 = Yookun
| location = Korea
| date = 1996
| accessdate = November 19, 2013
| separator = ,
}}
</ref>
<references/>

CSC 456 Fall 2013/4b cv

2013-11-19T17:07:41Z

Bvuong:

===Background===

Non-Uniform Memory (NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. Due to the access that this memory system is allowed in order to effectively utilize it there needs to be an efficient way of handling page management.

The NUMA system memory is managed in a node based model. The nodes consist CPUs, cache lines, and local memory that can communicate via a NUMA connector. This system creates page pools for each of the different nodes and can swap pages from each of these nodes using a swapper thread. The page pools contain free lists that hold the available pages; the active and inactive lists are used to manage page reclamation.

===History===

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
** demand fetching
** prefetching
* Placement - determining where to hold the page
** Fixed-Node
** Preferred-Node
** Random-Node
* Replacement - determining which page to remove for new pages
** Per-Task
** Per-Computation
** Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* random -

===Page Allocation Support in OpenMP===
* has directives for allocating blocks a certain way
** !dec$ migrate_next_touch(v1,...,v2) - migrates selected pages to referencing thread for easy access

CSC 456 Fall 2013/4b cv

2013-11-19T16:50:14Z

Bvuong:

CSC 456 Fall 2013/4b cv

2013-11-18T04:19:14Z

Bvuong: /* Different Strategies */

CSC 456 Fall 2013/4b cv

2013-11-17T01:10:32Z

Bvuong: /* Different Strategies */

===Background===

Non-Uniform Memory (NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. Due to the access that this memory system is allowed in order to effectively utilize it there needs to be an efficient way of handling page management.

The NUMA system memory is managed in a node based model. The nodes consist CPUs, cache lines, and local memory that can communicate via a NUMA connector. This system creates page pools for each of the different nodes and can swap pages from each of these nodes using a swapper thread. The page pools contain free lists that hold the available pages; the active and inactive lists are used to manage page reclamation.

===History===

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
** demand fetching
** prefetching
* Placement - determining where to hold the page
** Fixed-Node
** Preferred-Node
** Random-Node
* Replacement - determining which page to remove for new pages
** Per-Task
** Per-Computation
** Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* local to first access - waits
* local to first request

CSC 456 Fall 2013/4b cv

2013-11-17T01:10:18Z

Bvuong:

===Background===

Non-Uniform Memory (NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. Due to the access that this memory system is allowed in order to effectively utilize it there needs to be an efficient way of handling page management.

The NUMA system memory is managed in a node based model. The nodes consist CPUs, cache lines, and local memory that can communicate via a NUMA connector. This system creates page pools for each of the different nodes and can swap pages from each of these nodes using a swapper thread. The page pools contain free lists that hold the available pages; the active and inactive lists are used to manage page reclamation.

===History===

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
* * demand fetching
* * prefetching
* Placement - determining where to hold the page
* * Fixed-Node
* * Preferred-Node
* * Random-Node
* Replacement - determining which page to remove for new pages
* * Per-Task
* * Per-Computation
* * Global

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* local to first access - waits
* local to first request

CSC 456 Fall 2013/4b cv

2013-11-12T17:08:18Z

Bvuong: /* Different Strategies */

===Background===

Non-Uniform Memory (NUMA) technology has become the optimal solution for more complex systems in terms of the increase of processors. NUMA provides the functionality to distribute memory to each processor, giving each processor local access to its own share, as well as giving each processor the ability to access remote memory located in other processors. Due to the access that this memory system is allowed in order to effectively utilize it there needs to be an efficient way of handling page management.

The NUMA system memory is managed in a node based model. The nodes consist CPUs, cache lines, and local memory that can communicate via a NUMA connector. This system creates page pools for each of the different nodes and can swap pages from each of these nodes using a swapper thread. The page pools contain free lists that hold the available pages; the active and inactive lists are used to manage page reclamation.

===History===

===Different Strategies===
Page Allocation strategies are broken down to three categories when concerning with NUMA:
* Fetch - determining which page to be brought to main memory
* Placement - determining where to hold the page
* Replacement - determining which page to remove for new pages

* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* local to first access - waits
* local to first request

CSC 456 Fall 2013/4b cv

2013-10-31T15:48:19Z

Bvuong:

Wiki 2

===Background===

section 1: background
section 2: history
section 3: different strategies (general purposes and specific purposes)
(have charts)

types of strategies
* first touch - allocates the frame on the node that incurs the page fault, i.e. on the same node where the processor that accesses it resides.
* round robin - pages are allocated in different memory nodes and are accessed based on time slices.
* local to first access - waits
* local to first request

CSC 456 Fall 2013/1d vb

2013-09-17T16:24:33Z

Bvuong: /* Power Consumption vs. Performance */

=Trends in Pipelining=

==Introduction==

Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.

==Factors Favoring Longer Pipeline Length==
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work.

There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.

==Factors Favoring Shorter Pipeline Length==

The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple "best" pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.

Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]

==Power Consumption vs. Performance==
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan. The overall power/performance is improved with the number of pipeline stages, as illustrated in the graph.

[[File:Pipeline_stage_vs_metric.png]]

==Examples of Pipeline changes in Different Processors==

{| class="wikitable"
|+ Pipeline Specifications of Cray Systems
|-
! Year
! Name
! Pipeline Length
! Number of Pipelines
|-
| 1976
| Cray 1
| 3 [2]
| 12
|-
|2006
|IBM Cell BE
|23 [6]
|16
|-
| 2012
| Cray XK7
| 12 for scalar , 17 for vector [3]
| 6
|
|}

[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]

==Sources==
<ol>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CE4QFjAA&url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&ei=hQsmUv6LKMnJsASb8IGACQ&usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&sig2=fZvAhhwalsuZAs7GuamDHg&bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers] Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway </li>
<li>[http://en.wikipedia.org/wiki/Cray-1 Cray 1] Wikipedia</li>
<li>[http://en.wikipedia.org/wiki/XK7 Cray XK7] Wikipedia</li>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDkQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&ei=BwwmUtX-D7OgsQSrxYCgDw&usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&sig2=Hfx9Gs6MI8XtOVT3PvoDlw&bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, Thomas R. Puzak</li>
<li>[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi & Murakami</li>
<li>[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata</li>
</ol>

File:Pipeline stage vs metric.png

2013-09-17T16:24:04Z

Bvuong:

CSC 456 Fall 2013/1d vb

2013-09-17T16:22:52Z

Bvuong: /* Power Consumption vs. Performance */

=Trends in Pipelining=

==Introduction==

Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.

==Factors Favoring Longer Pipeline Length==
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work.

There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.

==Factors Favoring Shorter Pipeline Length==

The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple "best" pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.

Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]

==Power Consumption vs. Performance==
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan. The overall power/performance is improved with the number of pipeline stages, as illustrated in the graph.

[[File:Example.jpg]]

==Examples of Pipeline changes in Different Processors==

{| class="wikitable"
|+ Pipeline Specifications of Cray Systems
|-
! Year
! Name
! Pipeline Length
! Number of Pipelines
|-
| 1976
| Cray 1
| 3 [2]
| 12
|-
|2006
|IBM Cell BE
|23 [6]
|16
|-
| 2012
| Cray XK7
| 12 for scalar , 17 for vector [3]
| 6
|
|}

[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]

==Sources==
<ol>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CE4QFjAA&url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&ei=hQsmUv6LKMnJsASb8IGACQ&usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&sig2=fZvAhhwalsuZAs7GuamDHg&bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers] Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway </li>
<li>[http://en.wikipedia.org/wiki/Cray-1 Cray 1] Wikipedia</li>
<li>[http://en.wikipedia.org/wiki/XK7 Cray XK7] Wikipedia</li>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDkQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&ei=BwwmUtX-D7OgsQSrxYCgDw&usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&sig2=Hfx9Gs6MI8XtOVT3PvoDlw&bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, Thomas R. Puzak</li>
<li>[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi & Murakami</li>
<li>[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata</li>
</ol>

CSC 456 Fall 2013/1d vb

2013-09-17T16:22:14Z

Bvuong: /* Power Consumption vs. Performance */

=Trends in Pipelining=

==Introduction==

Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.

==Factors Favoring Longer Pipeline Length==
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work.

There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.

==Factors Favoring Shorter Pipeline Length==

The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple "best" pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.

Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]

==Power Consumption vs. Performance==
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan. The overall power/performance is improved with the number of pipeline stages, as illustrated in the graph.

==Examples of Pipeline changes in Different Processors==

{| class="wikitable"
|+ Pipeline Specifications of Cray Systems
|-
! Year
! Name
! Pipeline Length
! Number of Pipelines
|-
| 1976
| Cray 1
| 3 [2]
| 12
|-
|2006
|IBM Cell BE
|23 [6]
|16
|-
| 2012
| Cray XK7
| 12 for scalar , 17 for vector [3]
| 6
|
|}

[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]

==Sources==
<ol>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CE4QFjAA&url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&ei=hQsmUv6LKMnJsASb8IGACQ&usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&sig2=fZvAhhwalsuZAs7GuamDHg&bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers] Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway </li>
<li>[http://en.wikipedia.org/wiki/Cray-1 Cray 1] Wikipedia</li>
<li>[http://en.wikipedia.org/wiki/XK7 Cray XK7] Wikipedia</li>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDkQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&ei=BwwmUtX-D7OgsQSrxYCgDw&usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&sig2=Hfx9Gs6MI8XtOVT3PvoDlw&bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, Thomas R. Puzak</li>
<li>[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi & Murakami</li>
<li>[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata</li>
</ol>

CSC 456 Fall 2013/1d vb

2013-09-17T16:10:57Z

Bvuong: /* Power Consumption vs. Performance */

=Trends in Pipelining=

==Introduction==

Computing architectures have changed greatly over the relatively short span of a few decades. In the pursuit of good performance and economical cost, processor architectures have taken many forms. There have been many trends over the years relating to specific processor characteristics such as pipeline length. Some changes are based on technological limitations of the time period, and other decisions are based on hypothetical and real world performance research.

==Factors Favoring Longer Pipeline Length==
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very short. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work.

There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.

==Factors Favoring Shorter Pipeline Length==

The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple "best" pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.

Latch delays can also play a role when you increase pipeline Length. When you attempt to improve performance by increasing the number of stages more than 90% of the optimum performance, problems occur. The performance does not increase at this point unless the latch overhead time is addressed, requiring that the increasable latch overhead time is less than the total overhead time. [5]

==Power Consumption vs. Performance==
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan.

==Examples of Pipeline changes in Different Processors==

{| class="wikitable"
|+ Pipeline Specifications of Cray Systems
|-
! Year
! Name
! Pipeline Length
! Number of Pipelines
|-
| 1976
| Cray 1
| 3 [2]
| 12
|-
|2006
|IBM Cell BE
|23 [6]
|16
|-
| 2012
| Cray XK7
| 12 for scalar , 17 for vector [3]
| 6
|
|}

[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif A visual example of the Cell Pipeline]

==Sources==
<ol>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CE4QFjAA&url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&ei=hQsmUv6LKMnJsASb8IGACQ&usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&sig2=fZvAhhwalsuZAs7GuamDHg&bvm=bv.51495398,d.cWc The AMD Opteron Processor for Multiprocessor Servers] Chetana N. Keltcher, Kevin J. McGrath, Ardsher Ahmed, Pat Conway </li>
<li>[http://en.wikipedia.org/wiki/Cray-1 Cray 1] Wikipedia</li>
<li>[http://en.wikipedia.org/wiki/XK7 Cray XK7] Wikipedia</li>
<li>[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDkQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&ei=BwwmUtX-D7OgsQSrxYCgDw&usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&sig2=Hfx9Gs6MI8XtOVT3PvoDlw&bvm=bv.51495398,d.cWc The Optimum Pipeline Depth for a Microprocessor] A. Hartstein, Thomas R. Puzak</li>
<li>[http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en An Analysis about Increasable Latch Overheard time for Processor Pipeline Depth Increase] Magoshi & Murakami</li>
<li>[http://www.ibm.com/developerworks/power/library/pa-cellperf/ Cell Broadband Engine Architecture] Dr.Thomas Chen, Dr.Ram Raghavan, Jason Dale, Eiji Iwata</li>
</ol>

CSC 456 Fall 2013/1d vb

2013-09-10T18:36:00Z

Bvuong:

=Trends in Pipelining=

==Trends of Increasing Pipeline Length==
With each tick of the clock, the pipeline is advanced by one stage. Having a much longer pipeline allows for each individual step to be very small and precise. Since each individual pipeline step is relatively small it is possible for the clock speed to be much faster since each step does not require as much time or work.

There is a secondary affect of longer pipelines as well. The resulting higher clock speed can also be used as a marketing point. The average user does not understand the metrics of raw processor power, but being able to compare two numbers such as 2.9Ghz vs 3.4Ghz is a simple way in which many attempt to understand different processors.

==Trends of Decreasing Pipeline Length==

The issue with increased pipeline length is the problem of incorrect branch predictions. The longer a pipeline is, the more stages of wasted processing have been wasted when a different branch is taken. Decreasing the pipeline length has resulted in lower clock frequencies, but equal or better IPC. A smaller pipeline suffers less of a loss for every bad prediction, and the overall performance is improved. With all processor properties, there is no simple "best" pipeline, there is always a bell curve pointing to the the most effective pipeline pipeline length for a given setup.

Latch delays can also play a role when you increase pipeline Length..
" When a performance increase is attempted by further increasing the number of stages for a processor in which the number of stages is more than 90% of the optimum for performance, the performance is found not to be increased unless the increasable latch overhead time is less than the overhead time. " [5] - An Analysis about Increasable Latch Overhead Time for Processor Pipeline Depth Increase

==Power Consumption vs. Performance==
Along with performance, power is another concern in microarchitectural design. There have been multiple studies on what optimal pipeline depth when considering both performance and power. Srinivasan stated that majority of power used is related to latches, including clocking and the leakage of power per latch. The number of latches grows super linearly with the number of pipeline stages according to Srinivasan,

==An Example of Pipeline changes in Cray Systems==

{| class="wikitable"
|+ Pipeline Specifications of Cray Systems
|-
! Year
! Name
! Pipeline Length
! Number of Pipelines
|-
| 1976
| Cray 1 [2]
| 3
| 12
|-
|2006
|IBM Cell BE
|23
|8 SPEs * 2 threads
|-
| 2012
| Cray XK7 [3]
| 12 for scalar , 17 for vector
| 500 cabinets * 24 blades * 4 cores * 3 pipelines per chip
|
|}

[http://www.ibm.com/developerworks/power/library/pa-cellperf/figure2.gif An example of the Cell Pipeline]

==Sources==
<ol>
<li>https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CE4QFjAA&url=http%3A%2F%2Fclasses.soe.ucsc.edu%2Fcmpe202%2FFall04%2Fpapers%2Fopteron.pdf&ei=hQsmUv6LKMnJsASb8IGACQ&usg=AFQjCNHvPcgDLJjfk0ufcd7HRA6aDAgU8w&sig2=fZvAhhwalsuZAs7GuamDHg&bvm=bv.51495398,d.cWc</li>
<li>http://en.wikipedia.org/wiki/Cray-1</li>
<li>http://en.wikipedia.org/wiki/XK7</li>
<li>https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDkQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.93.4333%26rep%3Drep1%26type%3Dpdf&ei=BwwmUtX-D7OgsQSrxYCgDw&usg=AFQjCNFrDohjVe-SefuaJvLAJwXEFVgWYw&sig2=Hfx9Gs6MI8XtOVT3PvoDlw&bvm=bv.51495398,d.cWc</li>
<li>http://www.readcube.com/articles/10.1002/ecjc.20127?locale=en</li>
<li>http://dl.acm.org/citation.cfm?id=956566</li>
</ol>

CSC 456 Fall 2013/1d vb

2013-09-10T18:34:55Z

Bvuong: