1. Computer Science 320 Cache Interference

2. Unexpected Performance The testing of the partial key search SMP program produced anomalous results In particular, the efficiency and the experimentally determined sequential fraction EDSF were all over the place, when they should have been constant That indicates the presence of extra synchronicity, but where?

3. EDSF vs Processors

4. Efficiency vs Processors

5. Per Thread Variables and Memory // Thread local variables. byte[] trialkey; byte[] trialciphertext; AES256Cipher cipher; // Set up thread local variables. public void start(){ trialkey = new byte [32]; System.arraycopy(partialkey, 0, trialkey, 0, 32); trialciphertext = new byte [16]; cipher = new AES256Cipher(trialkey);

6. Mapping Variables to the Cache

7. The Source of Synchronicity The variables of threads 1 and 2 share the same cache line Thread 1 writes to its variable, which dirties the cache line Thread 2 must wait until the cache line is cleaned up (also called false sharing)

8. Solution: Add Padding to Variables Try to guarantee that a thread’s accessible data either fills a cache line or, if the data extends into another line, it’s never accessed by my thread If any data does extend beyond a cache line, it’s actually padding that the thread never accesses

9. Solution: Add Padding to Variables // Thread local variables. byte[] trialkey; byte[] trialciphertext; AES256Cipher cipher; // Extra padding long p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd, pe, pf; // Set up thread local variables. public void start(){ trialkey = new byte [32 + 128]; System.arraycopy(partialkey, 0, trialkey, 0, 32); trialciphertext = new byte [16 + 128]; cipher = new AES256CipherSmp(trialkey);

10. Efficiency Improvements?

11. EDSF Improvements?

12. Turn off the JIT compiler, which produces a larger ESDF