This blog is continuation of Scalable Counter post.
One of the reader shared result from his system. He ran test on XEON intel processor with 16 core and total time taken for each type of counter is almost same, although Atomic counter has CAS failure & other type does't has any CAS failure but it does't make any difference in execution time.
Very strange result , needs further investigation.
Another reader pointed out that it could be due to false sharing, so it worth to take that into account and i created another class that handles FALSE SHARING
Time take by different counter
Y Axis - Time taken to increment 1 Million times
X Axis - Number of threads
One of the reader shared result from his system. He ran test on XEON intel processor with 16 core and total time taken for each type of counter is almost same, although Atomic counter has CAS failure & other type does't has any CAS failure but it does't make any difference in execution time.
Very strange result , needs further investigation.
Another reader pointed out that it could be due to false sharing, so it worth to take that into account and i created another class that handles FALSE SHARING
Time take by different counter
X Axis - Number of threads
PaddedAtomicCounter is new type of counter that i have added to test & it it outperforms all other counters.
It is using cache line padding to avoid false sharing.
Cacheline is of 64 byte on most of the today processor. PaddedCounter it Integer based counter so it is adding 16 slot per counter, by using this techniques we avoid cache pollution & as result we see 16X times gain as compared to AtomicCounter, without padding the gain was 5X and with cache line padding gain jumps to 16X.
With cacheline padding you need some extra space, so it is trade off of memory for speed, you can choose what you want!
CAS failure rate
Lets look at the CAS failure for different counter & what it means for performance.
Y Axis - CAS Failure in 100Ks
X Axis - Number of threads
X Axis - Number of threads
PaddedAtomic has some CAS failure as compared to other counters , but it does't make any difference in execution time of the counter.
CAS failure is not the only factory that can determined execution time, false sharing make significant contribution to it, so this gives good explanation of behavior seen in XEON processor
Conclusion
To get better performance you have to take care of few things
- Contention - There are many techniques to avoid it , this blogs shows one of them
- False Sharing - You have to avoid false sharing to get best out of processor, padding is required for that. Some of the JDK classes are using padding are ThreadLocalRandom , now we have @Contended annotation from java to achive same thing, it is being used in ForkAndJoinPool
Code is available @ github
