Each question is marked with the date it was added. If there is no date, the question was the in the original version of the FAQ. If applicable, the writeup will be updated to reflect information from new questions.
The cache is write-allocate: If you want to write to an address, it must be in the cache first (and therefore you suffer a cache miss if it wasn't in there already).
The cache is write-through: Once a line is in the cache, any writes to it immediately appear in memory (and therefore immediately increase your score).
Finally, the cache automatically updates from memory: In particular, if you have the taunt array in cache, and a new bot enters dark_side mode, the taunt array in cache updates immediately.
It's possible to prefetch too early, such that the line you prefetch arrives in the cache while you're still working on a different line. In this case, you'll doubly penalize yourself, as you'll suffer a miss for the line you're currently accessing, and then miss on the line you meant to prefetch in the first place. Oops! Don't do that.
If you prefetch slightly late, you only lose the difference. If address 0x01000000 is not in the cache, but you prefetch it, wait 50 cycles, then try to write to/read from it, you'll still miss but only stall 50 cycles instead of the usual 100, since 50 of the cycles were alerady taken up by the prefetch. This is why prefetching is beneficial. If you run the simulator in "very verbose mode" via simulate -vvvv, you'll see messages like "upgrades existing prefetch", and this is the meaning of that message.
On the other hand, if address 0x01000400 is in the cache, you prefetch 0x01000200, then try to read/write 0x01000000, the prefetch is canceled, You miss 0x01000000, and stall the full 100 cycles, no matter how far along the prefetch was.
The earlier one sticks. The writeup already states "prefetch requests are ignored if a fetch is already in progress for that line", and in this context "fetch" means either an earlier prefetch or a core waiting on the cache line to fill due to a cache miss.
The writeup is updated to clarify this.
Snorlaxes are triggered when any core attempts to write to a memory location that currently holds the Trap! byte. Such an attempt causes the write to fail and the writing core to be stalled for 1,000,000 (STALL_WHEN_LAXPED) cycles. Since the write fails, multiple cores can be trapped at the same memory location.
Snorlaxes are not triggered by reading memory.