# Adaptive Versioning in Transactional Memory Systems +
## 6 Experimental Evaluation
### Evaluation of Adaptive in Persistent Memories
With the increase in number of threads, transaction abort rate also increases and total number of data movements in _Eager_ also starts to increase due to the frequent requirement of rollbacks. The results obtained for _genome_ and _kmeans-low_ show that _Eager_ starts to encounter more data movements than _Lazy_ beyond 8 threads. The same scenario starts beyond 4 threads in _Intruder_ and _yada_. Irrespective of the abort rate change, Adaptive always has less number of total data movements compared to the respective _eager_ and _lazy_ versioning. Specifically, _Adaptive_ETL_ has up to 6\(\times\) less data movements than _Lazy_ETL_ and up to 2\(\times\) less data movements than _Eager_. _Adaptive_CTL_ achieved up to 3\(\times\) less data movements compared to _Lazy_CTL_ and up to 35\(\times\) less data movements (in _yada_) compared to _Eager_. Figure 11 shows the results for total number of stores to the persistent memory. Similar to micro-benchmarks, _Lazy_ versioning has less number of PM stores than the _Eager_ versioning in STAMP benchmarks as well. In Adaptive versioning, total number of PM stores decreases compared to _Eager_ (up to 28\(\times\)) and increases compared to _Lazy_ (up to 2\(\times\)). Figure 12 shows the results for total number of aborts. Similar to micro-benchmarks, the total number of aborts in STAMP benchmarks also decreases when executing the transactions using Adaptive versioning. This is because the Adaptive versioning always tries to minimize the total data movements by adapting a suitable versioning method between _Eager_ and _Lazy_. In _Adaptive_ETL_, the total number of aborts are up to 3\(\times\) and 17\(\times\) less than _Eager_ and _Lazy_ETL_, respectively. In _Adaptive_CTL_, the total number of aborts are up to 240\(\times\) and 2.8\(\times\) less than _Eager_ and _Lazy_CTL_, respectively. Figure 9: Number of aborts in micro-benchmarks and _buges_ from STAMP in persistent TM. Figure 11: Total number of stores to the PM in STAMP benchmarks. Figure 10: Data movements in STAMP benchmarks executing in persistent TM. Results on STAMPEDE Benchmarks. Figure 13 provides the experimental results for total data movements. Similar to micro- and STAMP benchmarks, Adaptive has less number of total data movements compared to _Eager_ and _Lazy_ in STAMPEDE benchmarks as well. We observed that \(Adaptive\_ETL\) has up to 3.6\(\times\) less data movements than \(Lazy\_ETL\) and \(Adaptive\_CTL\) plus up to 6\(\times\) less data movements than \(Lazy\_CTL\). Compared to _Eager_, \(Adaptive\_ETL\) achieved up to 4.6\(\times\) less data movements and \(Adaptive\_CTL\) achieved up to 3.1\(\times\) less data movements. Figure 14 shows the experimental results for total number of PM stores in STAMPEDE benchmarks. It also follows the results obtained for micro- and STAMP benchmarks where _Lazy_ versioning has less number of PM stores than the _Eager_ versioning and Adaptive versioning lies between the two values. To be precise, \(Adaptive\_ETL\) has up to 64\(\times\) less number of PM stores than \(Eager\) and up to 2.7\(\times\) more number of PM stores than \(Lazy\_ETL\) whereas \(Adaptive\_CTL\) has up to 9\(\times\) less number of PM stores than _Eager_ and up to 18\(\times\) more number of PM stores than \(Lazy\_CTL\)  
The experimental results for the total number of aborts are shown in Figure 15. Again, similar to micro- and STAMP benchmarks, the total number of aborts in Adaptive versioning has been decreased compared to that in _Eager_ and _Lazy_ versioning. Precisely, \(Adaptive\_ETL\) has up to 14.3\(\times\) and 14.7\(\times\) less number of aborts compared to _Eager_ and _Lazy_ETL_, respectively. Similarly, \(Adaptive\_CTL\) has up to 2.7\(\times\) and 9.2\(\times\) less number of aborts compared to _Eager_ and _Lazy_CTL_, respectively. To summarize the above results, in all three benchmark suites, we observed that the total movements of data (i.e., loads and stores) and the total number of aborts in Adaptive versioning decrease compared to that in _Eager_ and _Lazy_ versioning.