Computer Science 320
Cache Interference
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?
EDSF vs Processors
Efficiency vs Processors
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);
Mapping Variables to the Cache
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)
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
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);
Efficiency Improvements?
EDSF Improvements?
EDSF Improvements?
Turn off the JIT compiler, which produces a larger ESDF