# Adaptive Versioning in Transactional Memory Systems +
## 6 Experimental Evaluation
### Evaluation of Adaptive in Persistent Memories  
For persistent memories, we ran the experiments using up to 16 threads and report the results accordingly with an average of 10 runs for each thread. We present 4 different types of results for each benchmark suite: (i) total data movements (including both loads from and stores to the persistent memory), (ii) total number of stores to the persistent memory, (iii) total number of aborts, and (iv) total execution time. We first discuss results for metrics (i)-(iii) separately for each benchmark suite and then we discuss results for metric (iv) together for all the benchmark suites. **Results on Micro-benchmarks. ** All the transactions in these benchmarks were run with _update rate_ of 20%. When transactions were executed with less number of threads, we found that the transaction commit rate is higher than the transaction abort rate and the cost in lazy versioning is higher than the cost in eager versioning. With the increase in number of threads, the abort rate is also increased. Figure 7-9 provide the experimental results on all five micro-benchmarks for total data movements, total number of stores to PM and total number of aborts, respectively. We noticed that \(Lazy\_CTL\) has consistently better performance than \(Lazy\_ETL\) on all the five micro-benchmarks. This is because the early detection of conflict and locking the memory addresses has increased abort rate than detecting the conflicts and locking the memory addresses at the commit time. We observed that the total number of aborts in Adaptive versioning has been decreased compared to that in both eager and lazy versioning. To be specific, \(Adaptive\_ETL\) has up to 1.5\(\times\) less number of aborts than \(Lazy\_ETL\) and up to 1.7\(\times\) less number of aborts than \(Eager\). Similarly, \(Adaptive\_CTL\) has upto 1.3\(\times\) less number of aborts than \(Lazy\_CTL\) and upto 3.8\(\times\) less number of aborts than \(Eager\). Figure 7 shows that the total data movements to and from the persistent memory (i.e., loads and stores to the PM) has been decreased in Adaptive versioning. \(Adaptive\_ETL\) has up to 3.4\(\times\) less data movements than \(Lazy\_ETL\) and up to 1.1\(\times\) less data movements than \(Eager\). \(Adaptive\_CTL\) has up to 3\(\times\) and 1.3\(\times\) less number of data movements compared to that in \(Lazy\_CTL\) and \(Eager\), respectively. Figure 8 shows the total number of stores to the PM. We can see that lazy versioning has less number of stores to the persistent memory. This is because the aborts in lazy versioning do not participate in stores to the persistent memory. On the other hand, in eager versioning, an abort requires the memory addresses to be rolled back to the previous consistent states, thus increasing the total number of stores to the PM. We observed that the total number of stores in Adaptive is always less than the \(Eager\) and is greater than \(Lazy\) in most of the cases. Compared to \(Eager\), \(Adaptive\_ETL\) has up to 1.4\(\times\) less number of PM stores and \(Adaptive\_CTL\) has up to 2.1\(\times\) less number of PM stores. Compared to \(Lazy\), \(Adaptive\_ETL\) has up to 1.8\(\times\) more number of PM stores and \(Adaptive\_CTL\) has up to 1.6\(\times\) more number of PM stores. We also noticed that \(Adaptive\_CTL\) performs better than \(Adaptive\_ETL\) in each micro-benchmark. This is because \(Lazy\_CTL\) performs better than \(Lazy\_ETL\) and \(Adaptive\_ETL\) was designed using \(Eager\) and \(Lazy\_ETL\) whereas \(Adaptive\_CTL\) was designed using \(Eager\) and \(Lazy\_CTL\), respectively. Figure 8: Total number of stores to the PM in micro-benchmarks and _bayes_ from STAMP. Figure 7: Data movements in micro-benchmarks and _bayes_ from STAMP executing in persistent TM. **Results on STAMP Benchmarks. ** Figure 10 provides total data movement results. It is obvious that when transactions are executed with less number of threads, transaction commit rate is higher and there is less number of total data movements _Eager_ than _Lazy_.