CSC/ECE 506 Spring 2011/ch6a ep - Revision history

Eapotter: /* Recent Architectures and their Cache Characteristics */

2011-03-08T04:23:37Z

Recent Architectures and their Cache Characteristics

← Older revision		Revision as of 04:23, 8 March 2011
Line 323:		Line 323:
	Note: The 'x #' in the L1 and L2 columns indicates that this cache is for each core.		Note: The 'x #' in the L1 and L2 columns indicates that this cache is for each core.

	The next two sections will discuss cache write policies and cache prefetching as techniques to improve ~~cache~~ performance by reducing write-miss and read-miss rates.		The next two sections will discuss cache write policies and cache prefetching as techniques to improve the performance of these complex caching architectures by reducing write-miss and read-miss rates.

	=Cache Write Policies[[#References\|[5]]]=		=Cache Write Policies[[#References\|[5]]]=

Eapotter: /* Recent Architectures and their Cache Characteristics */

2011-03-08T04:22:02Z

Recent Architectures and their Cache Characteristics

← Older revision		Revision as of 04:22, 8 March 2011
Line 323:		Line 323:
	Note: The 'x #' in the L1 and L2 columns indicates that this cache is for each core.		Note: The 'x #' in the L1 and L2 columns indicates that this cache is for each core.

	The next two sections will discuss cache write policies and cache prefetching as ~~two~~ techniques improve cache performance by reducing write-miss and read-miss rates.		The next two sections will discuss cache write policies and cache prefetching as techniques to improve cache performance by reducing write-miss and read-miss rates.

	=Cache Write Policies[[#References\|[5]]]=		=Cache Write Policies[[#References\|[5]]]=

Eapotter: /* Recent Architectures and their Cache Characteristics */

2011-03-08T04:20:40Z

Recent Architectures and their Cache Characteristics

← Older revision		Revision as of 04:20, 8 March 2011
Line 322:		Line 322:

	Note: The 'x #' in the L1 and L2 columns indicates that this cache is for each core.		Note: The 'x #' in the L1 and L2 columns indicates that this cache is for each core.

			The next two sections will discuss cache write policies and cache prefetching as two techniques improve cache performance by reducing write-miss and read-miss rates.

	=Cache Write Policies[[#References\|[5]]]=		=Cache Write Policies[[#References\|[5]]]=

Eapotter: /* Prefetching in Contemporary Parallel Processors */

2011-03-08T04:15:34Z

Prefetching in Contemporary Parallel Processors

← Older revision		Revision as of 04:15, 8 March 2011
Line 381:		Line 381:
	Prefetching is a technique that can be used in addition to write-hit and write-miss policies to improved the utilization of the cache. Microprocessors, such as those listed in Table 1, support prefetching logic directly in the chip.		Prefetching is a technique that can be used in addition to write-hit and write-miss policies to improved the utilization of the cache. Microprocessors, such as those listed in Table 1, support prefetching logic directly in the chip.

	Prefetching is the process of retrieving instructions or data from memory before the process explicitly requests it. Instruction prefetching is commonly used by single and multiprocessors to reduce process wait states.[[#References\|[17]]] Prefetching of data may also be used, though, to pre-populate caches with data that is likely going to be required by the processors in the near term. If the data requirements are anticipated correctly, the requests to memory will result in a greater ~~percentage of~~ cache hit rates and, therefore, reduce overall memory access time. If the prefetcher guesses wrong, bus traffic can increase unnecessarily, more relevant data can be flushed from caches, and miss rates can increase.		Prefetching is the process of retrieving instructions or data from memory before the process explicitly requests it. Instruction prefetching is commonly used by single and multiprocessors to reduce process wait states.[[#References\|[17]]] Prefetching of data may also be used, though, to pre-populate caches with data that is likely going to be required by the processors in the near term. If the data requirements are anticipated correctly, the requests to memory will result in a greater cache hit rates and, therefore, reduce overall memory access time. If the prefetcher guesses wrong, bus traffic can increase unnecessarily, more relevant data can be flushed from caches, and miss rates can increase.

	Prefetching algorithms can leverage both temporal and spacial locality in making these decisions. For example, streaming and sequential access applications often process adjacent memory locations in subsequent tasks.		Prefetching algorithms can leverage both temporal and spacial locality in making these decisions. For example, streaming and sequential access applications often process adjacent memory locations in subsequent tasks.

Eapotter: /* Cache Write Policies[5] */

2011-03-08T04:14:12Z

Cache Write Policies[5]

← Older revision		Revision as of 04:14, 8 March 2011
Line 326:		Line 326:
	In section 6.2.3[[#References\|[8]]], cache write hit policies and write miss policies were explored. The write hit policies, write-through and write-back, determine when the data written in the local cache is propagated to lower-level memory. As review, write-through writes data to the cache and memory on a write. Write-back writes to cache first and to memory only when a flush is required.		In section 6.2.3[[#References\|[8]]], cache write hit policies and write miss policies were explored. The write hit policies, write-through and write-back, determine when the data written in the local cache is propagated to lower-level memory. As review, write-through writes data to the cache and memory on a write. Write-back writes to cache first and to memory only when a flush is required.

	The write miss policies covered in the text[[#References\|[8]]] write-allocate and no-write-allocate, determine if a memory block is stored in a cache line after the write occurs. Note that since a miss occurred on write, the block is not already in a cache line.		The write miss policies covered in the text[[#References\|[8]]], write-allocate and no-write-allocate, determine if a memory block is stored in a cache line after the write occurs. Note that since a miss occurred on write, the block is not already in a cache line.

	Write-miss policies can also be expressed in terms of write-allocate, fetch-on-write, and write-before-hit. These can be used in combination with the same write-through and write-back hit policies to define the complete cache write policy. Investigating alternative policies such as these is important since write-misses produce on average one-third of all cache misses.		Write-miss policies can also be expressed in terms of write-allocate, fetch-on-write, and write-before-hit. These can be used in combination with the same write-through and write-back hit policies to define the complete cache write policy. Investigating alternative policies such as these is important since write-misses produce on average one-third of all cache misses.

Eapotter: /* Write-Invalidate */

2011-03-08T04:10:40Z

Write-Invalidate

← Older revision		Revision as of 04:10, 8 March 2011
Line 373:		Line 373:
	The combination of write-before-hit, no-fetch-on-write, and no-write-allocate is referred to as 'write-invalidate' because the line is invalidated on the miss. The copy that exists in lower level memory after the write miss differs from the one in the cache. For write hits, though, the data is simply written into the cache using the cache hit policy. Thus, for hits, the cache is not written around.		The combination of write-before-hit, no-fetch-on-write, and no-write-allocate is referred to as 'write-invalidate' because the line is invalidated on the miss. The copy that exists in lower level memory after the write miss differs from the one in the cache. For write hits, though, the data is simply written into the cache using the cache hit policy. Thus, for hits, the cache is not written around.

			Of these three combinations, write validate performed the worse. The author notes, though, that it does perform better than fetch-on-write and is easy to implement. Tests by the author demonstrated a 35-50% reduction in write misses when compared to fetch-on-write policies.
	Of these three combinations, write validate performed the worse. The author notes, though, that it does perform better than fetch-on-write and is easy to implement.

	===Fetch-on-write===		===Fetch-on-write===

Eapotter: /* Write-Around */

2011-03-08T04:10:15Z

Write-Around

← Older revision		Revision as of 04:10, 8 March 2011
Line 367:		Line 367:

	The author notes that in only but a few cases write-around performs worse than write-validate policies. Most applications tend to reread what they have recently written. Using a write-around policy, this would result in a cache miss and a read from lower-level memory. With write-validate, the data would be in cache.		The author notes that in only but a few cases write-around performs worse than write-validate policies. Most applications tend to reread what they have recently written. Using a write-around policy, this would result in a cache miss and a read from lower-level memory. With write-validate, the data would be in cache.

			Tests by the author demonstrated a 40-70% reduction in write misses when compared to fetch-on-write policies.

	===Write-Invalidate===		===Write-Invalidate===

Eapotter: /* Write-Validate */

2011-03-08T04:09:42Z

Write-Validate

← Older revision		Revision as of 04:09, 8 March 2011
Line 360:		Line 360:

	The no-fetch-on-write has the advantage of avoiding an immediate bus transaction to retrieve the block from memory. For a multiprocessor with a cache coherency model, though, a bus transaction will be required to get exclusive ownership of the block. While this appears to negate the advantages of no-fetch-on-write, the process is able to continue other tasks while this transaction is occurring, including rewriting to the same cache location.		The no-fetch-on-write has the advantage of avoiding an immediate bus transaction to retrieve the block from memory. For a multiprocessor with a cache coherency model, though, a bus transaction will be required to get exclusive ownership of the block. While this appears to negate the advantages of no-fetch-on-write, the process is able to continue other tasks while this transaction is occurring, including rewriting to the same cache location.

			Tests by the author demonstrated more than a 90% reduction in write misses when compared to fetch-on-write policies.

	===Write-Around===		===Write-Around===

Eapotter: /* Intel Core i7 [6] */

2011-03-08T04:00:13Z

Intel Core i7 [6]

← Older revision		Revision as of 04:00, 8 March 2011
Line 389:		Line 389:
	The Data Cache Unit prefetcher is a streaming prefetcher for L1 caches that detects ascending access to data that has been loaded very recently. The processor assumes that this ascending access will continue, and prefetches the next line.		The Data Cache Unit prefetcher is a streaming prefetcher for L1 caches that detects ascending access to data that has been loaded very recently. The processor assumes that this ascending access will continue, and prefetches the next line.

	The data prefetch logic (DPL) maintains two arrays to track the recent accesses to memory: one for the upstreams that has 12 entries, and one for downstreams that has 4 entires. As pages are accessed, their ~~address is~~ tracked in these arrays. When the DPL detects an access to a page that is sequential to an existing entry, it assumes this ~~stream~~ will continue, and prefetches the next cache line from memory.		The data prefetch logic (DPL) maintains two arrays to track the recent accesses to memory: one for the upstreams that has 12 entries, and one for downstreams that has 4 entires. As pages are accessed, their addresses are tracked in these arrays. When the DPL detects an access to a page that is sequential to an existing entry, it assumes this sequential access will continue, and prefetches the next cache line from memory.

	== AMD [[#References\|[7]]]==		== AMD [[#References\|[7]]]==

Eapotter: /* Fetch-on-write */

2011-03-08T03:58:45Z

Fetch-on-write

← Older revision		Revision as of 03:58, 8 March 2011
Line 373:		Line 373:

	===Fetch-on-write===		===Fetch-on-write===
	When used with write-allocate, fetch-on-write stores the block and processes the write to cache as expected.		When used with write-allocate, fetch-on-write stores the block and processes the write to cache as expected. This policy was used as the base-line for determining the performance of the other three policy combinations. In general, all three previous combinations exhibited fewer misses than this policy.

	=Prefetching in Contemporary Parallel Processors=		=Prefetching in Contemporary Parallel Processors=