• No results found

Challenge analysis and quantification

• The second value is the result of aggregating all the values from T00 to TN in the same tile. This would be the value obtained without doing any modification in the system. However, as stated before, this second statistic accounts for requests from different prefetches and is not representative of any one in particular. For this reason this is not an accurate value.

We use the tagged prefetcher not the GHB prefetcher because, due to the pattern detection challenge, the latter is irrelevant.

Hardware specifications Values

ISA x86

CPU model TimingSimple Number of tiles 64

L1 Data cache size 16KB per tile L1 Instruction cache size 16KB per tile L2 Unified cache size 16MB

Network Garnet

Topology Mesh

Prefetcher cache level L2

Simulated cycles 350 millions Tagged prefetch aggr/dist 2/2

GHB depth/width 4/4

Table 6.1 Simulator specifications.

6.4

Challenge analysis and quantification

The framework consists of a mesh composed by 64 tiles with private first level data and instruction caches, and a shared L2 cache. The L2 cache comprises several banks and each of these banks is associated with a local tile. Each memory address is deterministically associated with a given L2 location. This means that there is no replication in the L2 cache, though a given block can be in several L1 caches. L2 and L1 are not inclusive. The coherence protocol employed is the MOESI CMP directory. The prefetchers used to quantify the challenges are the tagged prefetcher [24] and the GHB [59]. The hardware specifications are shown in Table 6.1. The simulator used for the analysis was gem5 [7] and the benchmark suite in this performance study was a subset of the PARSEC 2.1 benchmark suite [6].

With this simulation infrastructure, we have analyzed and quantified the error of each challenge following the methodology indicated in the previous section. Results are shown in the next subsections.

6.4.1

Pattern detection

As we stated earlier, we used the GHB prefetcher to analyze this challenge. This prefetcher records the miss stream of the memory it is working with, analyzes it, and attempts to find a correlation between the last accesses. If successful, it can trigger up to 16 prefetching requests (depending on the aggressiveness) per memory miss. Figure 6.6a shows the evaluation of all the requests issued. The total value of the bars represents the number of generated requests every 1k instructions. Note that a distributed GHB can only be aware of certain parts of the pattern. For this reason, it is unable to find correlation in the miss stream and is therefore unable to generate prefetch requests. The unified and ideal GHB therefore launches up to 6.5 times more useful prefetches than the distributed one.

(a) Evaluation of the generated requests by GHB and the ideal GHB for the pattern detection chal- lenge analysis.

(b) MPKI in L2 without prefetching, GHB, and ideal GHB for the pattern detection challenge anal- ysis.

Fig. 6.6 Pattern detection challenge analysis.

Figure 6.6b shows the misses every 1k instructions. As a consequence of a prefetch engine that is not working properly, the MPKI is not reduced as much as it should be. We can see that in almost all the workloads the ideal GHB reduces the MPKI to a higher degree than the distributed GHB does. However, in the canneal benchmark, the MPKI of the ideal GHB is higher than the distributed GHB. The reason for this is that the GHB engine is not smart enough to predict the data required by this benchmark. Increasing the activity of the prefetcher therefore means increasing the pollution and, consequently, the MPKI.

6.4 Challenge analysis and quantification 129

Nevertheless, on average, the ideal GHB manages to decrease the MPKI to a higher degree than the distributed GHB does.

6.4.2

Prefetching queue filtering

To analyze this challenge we used a global filtering buffer. This buffer is aware of all the prefetch requests in all the prefetch queues. When queuing new requests, if the request is in any other queue of the system, it is merged. Figure 6.7a shows not only the issued requests but also the generated ones. The stacked bar with the filter buffer merge value represents the number of requests that the distributed prefetcher queue is not able to filter. For this reason, without the filtering buffer, the prefetcher will inject up to 30% more traffic into the network. Figure 6.7b shows the average latency of a miss in L1. We can see that the filtering has a direct effect on performance. This is because the filtering effect reduces congestion in the network, which reduces the L1 miss latency.

(a) Average number of generated requests by the Tagged prefetcher for the prefetching queue filter- ing.

(b) Average miss latency in L1 for all the bench- marks for the prefetching queue filtering.

Fig. 6.7 Queue filtering challenge analysis.

6.4.3

Dynamic profiling

To quantify this challenge, we measured the accuracy of the prefetcher in two ways: (1) the real accuracy for each prefetch in each tile and (2) the accuracy measured blindly in each tile

(a) Absolute error in accuracy for the Tagged prefetcher for the dynamic profiling analysis.

(b) Absolute error for all the tiles with the dedup benchmark for the dynamic profiling analysis.

Fig. 6.8 Dynamic profiling challenge analysis.

for the aggregated prefetching requests issued in it. We calculated the absolute error between these two values and the result is shown in Figure 6.8a and Figure 6.8b. In Figure 6.8a, we can see two elements: the bars, whose value represents the average error among all the tiles and the segment bars, which represent the maximum and minimum errors among all the tiles in the same chip. We can see that the error for some benchmarks is relatively small. This happens because, depending on the behavior of the tagged prefetch, the requests issued from one tile are almost always addressed to the same tile and this effect balances out the statistic. However, the error becomes significant when it is analyzed dynamically.

To see the error in the various tiles in greater detail, Figure 6.8b shows the absolute errors for all the tiles in the dedup benchmark, which is the one with the greatest errors. We can see that the error can sometimes reach differences of over 35%. Note that dynamic mechanisms, which base their decisions on these statistics, may make wrong decisions.