# PCS - Lab 2
De Baets Robin, De Buck Manu

## Q1

L1.1 Data Cache Stats: 
	Hits:      9835723
	Misses:    164277
	Accesses:  10000000

Bus Stats: 
	busReads:     67043
	busWrites:    97234
	busUpgrades:  0

Dram Stats: 
	Access:  299840
	Reads:   164277
	Written: 135563

	Data read:   10267 kbyte
	Data written: 8472 kbyte

| Cache miss rate (%) | Data written (kbyte) | Data read (kbyte) |
| - | - | - |
| 1.64277 | 8472 | 10267 |

## Q2

There is no actual cache coherence protocol between the multiple cores. If one core WB a CacheBlock, another core is not notified that it needs to invalidate the CacheBlock and will then use invalid CacheBlocks leading to errors. This obviously can not happen using one core.

## Q3

L1.1 Data Cache Stats: 
	Hits:      2788781
	Misses:    163502
	Accesses:  2952283
L1.2 Data Cache Stats: 
	Hits:      2533959
	Misses:    186925
	Accesses:  2720884
L1.3 Data Cache Stats: 
	Hits:      2072075
	Misses:    172513
	Accesses:  2244588
L1.4 Data Cache Stats: 
	Hits:      1904897
	Misses:    177348
	Accesses:  2082245

Bus Stats: 
	busReads:     611474
	busWrites:    88814
	busUpgrades:  0

Dram Stats: 
	Access:  808675
	Reads:   110432
	Written: 698243

	Data read:   6902 kbyte
	Data written: 43640 kbyte

| Cache miss rate (%) | Data written (kbyte) | Data read (kbyte) |
| - | - | - |
| 7.00288 | 43640 | 6902 |

* Due to constantly invalidating CacheBlocks and also writing them back (if previously in the **Modified** state), a lot more bytes are written to the DRAM memory in contrast to one core that does not need to invalidate and writeback (that often). This protocol allows only one core to have a cache block at a single point in time, when multiple cores constantly need the same cacheblock this will lead to a lot of WB's.
* There are fewer bytes read from DRAM because it is possible that one core wants to read a cacheblock another core is holding in it's cache. In this case, the cacheblock is send immediately to the other core instead of retrieving it from the DRAM memory.
* There are a lot more bus reads than the single core execution, since the different cores are constantly communicating with each other.

## Q4

The performance will be worse, because we're using multiple cores with this configuration. This causes writebacks to DRAM, which carry a big overhead. The execution will be much slower than using one core (which writes much less to DRAM). This is because DRAM is a slow component compared to the cache.

## Q5

A cacheblock consists of multiple bytes. If our write operation only writes to a subsection of these bytes, we need the current value of the other bytes. To do this, we fetch the part of the cacheblock that we don't write to. If we didn't do this, we would not know which other bytes to put in our cacheblock besides the ones we're writing. This means we would be throwing away previous writes.

## Q6

A cacheblock is in the exclusive state when a fetched cacheblock is received from DRAM and not from the cache of another core -- since there is only one copy of it. This means we have a single unique copy of the cacheblock. The cacheblock stays in the exclusive state as long as it hasn't been written to. This means that it matches the contents from main memory.

The problem that this solves is preventing a writeback when the cacheblock is evicted or invalidated, but was not yet modified. Using the exclusive state, we know a writeback to main memory is not necessary.

## Q7

L1.1 Data Cache Stats: 
	Hits:      2788781
	Misses:    163502
	Accesses:  2952283
L1.2 Data Cache Stats: 
	Hits:      2533959
	Misses:    186925
	Accesses:  2720884
L1.3 Data Cache Stats: 
	Hits:      2072075
	Misses:    172513
	Accesses:  2244588
L1.4 Data Cache Stats: 
	Hits:      1904897
	Misses:    177348
	Accesses:  2082245

Bus Stats: 
	busReads:     611474
	busWrites:    88814
	busUpgrades:  0

Dram Stats: 
	Access:  213675
	Reads:   110432
	Written: 103243

	Data read:   6902 kbyte
	Data written: 6452 kbyte

| Cache miss rate (%) | Data written (kbyte) | Data read (kbyte) |
| - | - | - |
| 7.00288 | 6452 | 6902 |

We can see that the problem is indeed solved (we now only write 6452 bytes to DRAM instead of 43640 bytes).
Nevertheless we can see the number of bytes read from DRAM is still the same the same as in the MI protocol.

We can also see that our number of bus reads is significantly higher than the single-core execution. Our average cache miss rate is also higher than in the single-core execution. Because a cache block can only be held by a single cache, there will be a cache miss when another core wants to read this data. This happens very often.
When multiple cores need the same data, it will constantly be transferred between their caches, which has a bad impact on performance.

## Q8

A cacheblock has a shared state when the cacheblock being read is not coming from DRAM but coming from another core that had a shared or exclusive cacheblock -- note that this cacheblock can not be modified yet. This state solves the problem we explained in Q7, where we were constantly transferring a cacheblock that was not modified yet between different cores .

## Q9

L1.1 Data Cache Stats: 
	Hits:      2911875
	Misses:    40408
	Accesses:  2952283
L1.2 Data Cache Stats: 
	Hits:      2696024
	Misses:    24860
	Accesses:  2720884
L1.3 Data Cache Stats: 
	Hits:      2218736
	Misses:    25852
	Accesses:  2244588
L1.4 Data Cache Stats: 
	Hits:      2060637
	Misses:    21608
	Accesses:  2082245

Bus Stats: 
	busReads:     23918
	busWrites:    88810
	busUpgrades:  354

Dram Stats: 
	Access:  212556
	Reads:   109313
	Written: 103243

	Data read:   6832 kbyte
	Data written: 6452 kbyte

| Cache miss rate (%) | Data written (kbyte) | Data read (kbyte) |
| - | - | - |
| 1.112728 | 6452 | 6832 |

The problem explained in Q7 is indeed solved, as we can see fewer bus reads are being performed (23918 instead of 611474) and the cache miss rate also became lower.

## Q10

L1.1 Data Cache Stats: 
	Hits:      2911875
	Misses:    40408
	Accesses:  2952283
L1.2 Data Cache Stats: 
	Hits:      2696117
	Misses:    24767
	Accesses:  2720884
L1.3 Data Cache Stats: 
	Hits:      2218828
	Misses:    25760
	Accesses:  2244588
L1.4 Data Cache Stats: 
	Hits:      2060737
	Misses:    21508
	Accesses:  2082245

Bus Stats: 
	busReads:     112443
	busUpdates:   1303452

Dram Stats: 
	Access:  211678
	Reads:   108879
	Written: 102799

	Data read:   6804 kbyte
	Data written: 6424 kbyte

| Cache miss rate (%) | Data written (kbyte) | Data read (kbyte) |
| - | - | - |
| 1.112443 | 6452 | 6804 |

We can see that the amount of bus reads is higher than the MEI protocol (112443 instead of 23916). This would lead to bad scalability on large multiprocessors since a lot of traffic on the bus yields large overhead on the performance of the processor across the different cores.

## Q11

A cacheblock is in the **shared modified** state if the cacheblock is not a unique copy and it has been modified and other cores are not yet aware of the modification. It is in **shared clean** state if it is not a unique copy if it *may* not be up-to-date in memory. The DRAGON protocol only uses BU if a cacheblock is in one of these shared states. This change in the protocol will solve the large amounts of traffic on the bus the previous protocol suffered from.

## Q12

L1.1 Data Cache Stats: 
	Hits:      2911875
	Misses:    40408
	Accesses:  2952283
L1.2 Data Cache Stats: 
	Hits:      2696117
	Misses:    24767
	Accesses:  2720884
L1.3 Data Cache Stats: 
	Hits:      2218828
	Misses:    25760
	Accesses:  2244588
L1.4 Data Cache Stats: 
	Hits:      2060737
	Misses:    21508
	Accesses:  2082245

Bus Stats: 
	busReads:     112443
	busUpdates:   199480

Dram Stats: 
	Access:  211678
	Reads:   108879
	Written: 102799

	Data read:   6804 kbyte
	Data written: 6424 kbyte

| Cache miss rate (%) | Data written (kbyte) | Data read (kbyte) |
| - | - | - |
| 1.112443 | 6424 | 6804 |

We can see this problem is indeed solved since now there are only 199480 bus updates compared to 1303452 in the update protocol.

## Q13

No problems will arise when we leave it in the shared state, but if we are certain the cacheblock is unique we can put it in the modified state, avoiding future bus update calls when rewriting to the cache block and thus avoiding unnecessary bus operations.