# Adaptive Versioning in Transactional Memory Systems +
## 6 Experimental Evaluation
### Evaluation of Adaptive in Persistent Memories
This helps us to achieve better execution time in Adaptive. Particularly, as the number of aborts decrease in Adaptive design compared to the non-adaptive baselines, there will be less number of transaction restarts as well as less number of data movements which ultimately reduces the total execution time of the transactions. We present the execution time results for all three benchmark suites in the next sub-section. We also observed that the total number of  
Figure 12: Total number of aborts in STAMP benchmarks in persistent TM. stores to persistent memories in Adaptive versioning are decreased compared to \(Eager\). However, compared to \(Lazy\), they are increased in Adaptive versioning. Figure 14: Total number of stores to the PM in STAMPEDE benchmarks. Figure 13: Data movements in STAMPEDE benchmarks executing in persistent TM. **Execution Time Results for Persistent Memories. ** Execution time is impacted in Adaptive due to the switching between eager and lazy versioning at runtime. Additionally, the design of time barrier also introduces time delay in some benchmarks. In most of the benchmarks, the delay due to time barrier is compensated as Adaptive lowers the data movements and the number of aborts. We were interested to see the maximum increase on time in any benchmark that we used in our experimentation. The results obtained for micro-benchmarks are shown in Figure 16. Recall that, for micro-benchmarks, we measured the execution time for 10,000 transactions, each executed with an update rate of 20%. All the 5 micro-benchmarks were executed with the five different versioning designs and the total number of transactions for each design were counted. We noticed that, in most of the applications, execution time in Adaptive decreases compared to that in both _Eager_ and _Lazy_ versioning. This is due to the decrease in total number of data movements and total number of aborts in Adaptive versioning. In _Adaptive_ETL_, execution time decreases by up to 21% compared to _Lazy_ETL_ and up to 17% compared to _Eager_. In _Adaptive_CTL_, execution time decreases by up to 28% compared to _Lazy_CTL_ and up to 33% compared to _Eager_. However, in some applications (for example see the results for _bank_ and _linked list_), the execution time in Adaptive increases compared to that in _Eager_ or _Lazy_ versioning. This is because the decrease in number of aborts is significantly less and is insufficient to compensate the overhead due to barrier and switching between the versioning methods. In _bank_ micro-benchmark, we noticed that the execution time in _Adaptive_CTL_ increases by up to 9% compared to _Lazy_CTL_. In _linked list_, the execution time in _Adaptive_CTL_ increases by up to 12% compared to _Lazy_CTL_ and the execution time in _Adaptive_ETL_ increases by up to 10% compared to _Lazy_ETL_. Figure 7:0 Total number of aborts in STAMPEDE benchmarks in persistent TM. For the STAMP and STAMPEDE benchmarks, we measured the execution time for each of the applications. Figures 17 and 18 illustrate the execution time results for the STAMP and STAMPEDE benchmarks, respectively. As Adaptive lowers the data movements and the number of aborts, most of the applications (e.g., bayes, kmeans high, labyrinth, ssca2 and vacation high in Figures 17 and 18) have decreased execution time in Adaptive than in _Eager_ or _Lazy_ designs. However, in some applications (e.g., genome, intruder and yada), we noticed that the execution time in Adaptive increases by at most 16% more compared to the execution time of _Eager_ or _Lazy_. We observed that the experimental results presented above for the execution time in persistent TM barely scale in throughput beyond 8 threads. This occurred due to the experimental environment used for conducting the tests. For persistent TM, the tests were executed on an Intel Corei7-7700K 4.20 GHz, 64-bit Haswell processor with 4 cores, each with 2 hyper threads. That means, it has 4 physical cores and 8 logical cores. Now, up to 8 threads, each process core handles an individual thread.