# Adaptive Versioning in Transactional Memory Systems +
## 6 Experimental Evaluation
### Evaluation of Adaptive in Non-Persistent Memories  
We report the results from experiments performed using up to 32 threads. The evaluation is on performance metrics metrics execution time and number of aborts. **Results on Micro-benchmarks. ** The execution time results in five different micro-benchmarks are provided in Figure 19. Figure 20 provides the result for the number of aborts. The results are for 10,000 transactions, each executed with _update rate_ of 20%. Figure 19 shows that the execution time decreases notably in Adaptive as compared to the other versioning methods with the increase in number of threads for all the micro-benchmarks. Specifically, \(Adaptive\_ETL\) achieved up to 6.3\(\times\) better execution time than \(Lazy\_ETL\) and \(Adaptive\_CTL\) achieved up to 3.7\(\times\) better execution time than \(Lazy\_CTL\). Compared to \(Eager\), \(Adaptive\_ETL\) achieved up to 5.5\(\times\) better execution time and \(Adaptive\_CTL\) achieved up to 5\(\times\) better execution time. The minimum execution gain for \(Adaptive\_ETL\) beyond 4 number of threads is 1.23 and for \(Adaptive\_CTL\) is 1.20. Due to high contention for memory access when transactions are executed with more number of threads, the number of aborts increases with the increasing number of threads. Figure 20 shows that Adaptive minimizes number of aborts. Specifically, \(Adaptive\_ETL\) achieved up to 2.6\(\times\) less number of aborts than \(Lazy\_ETL\) and up to 5.8\(\times\) less number of aborts than \(Eager\). \(Adaptive\_CTL\) achieved up to 2.2\(\times\) less number of aborts than \(Lazy\_CTL\) and up to 8\(\times\) less number of aborts than \(Eager\). **Results on STAMP Benchmarks. ** Figures 21 and 22, respectively, provide the execution time and number of aborts results. Regarding execution time, \(Adaptive\_ETL\) has up to 1.78\(\times\) better time than \(Lazy\_ETL\) and \(Adaptive\_CTL\) has up to 1.74\(\times\) better time than \(Lazy\_CTL\). Compared to \(Eager\), the execution time improvement in \(Adaptive\_ETL\) and \(Adaptive\_CTL\) is up to 2.36\(\times\) and 2\(\times\), respectively. The minimum execution gain obtained in \(Adaptive\_ETL\) is 1.13 and in \(Adaptive\_CTL\) is 1.12 with the threads grater than 4. From Figure 22, we observed that the number of aborts significantly increases in all the applications of STAMP benchmark when transactions are executed in more than 8 number of threads. Still, Adaptive has significantly less aborts compared to \(Lazy\) and \(Eager\). \(Adaptive\_ETL\) has up to 16\(\times\) less aborts than \(Lazy\_ETL\) and up to 13\(\times\) less aborts than \(Eager\). Similarly, \(Adaptive\_CTL\) has up to 2.5\(\times\) less aborts than \(Lazy\_CTL\) and up to 170\(\times\) less aborts than \(Eager\). Figure 19: Execution time in micro-benchmarks and bayes from STAMP using better time barrier in non-persistent TM. Figure 21: Execution time in STAMP benchmarks using better time barrier in non-persistent TM. Figure 20: Number of aborts in micro-benchmarks and bayes from STAMP using better time barrier in non-persistent TM. Results on STAMPEDE Benchmarks.Similar to micro and STAMP benchmarks, Adaptive has better performance compared to _Lazy_ and _Eager_ in STAMPEDE benchmarks, for both execution time and number of aborts (Figures 23 and 24). For execution time, _Adaptive_ETL_ performed up to 1.72\(\times\) better than _Lazy_ETL_ and _Adaptive_CTL_ performed up to 1.54\(\times\) better than _Lazy_CTL_. Compared to _Eager_, _Adaptive_ETL_ performed up to 1.68\(\times\) better and _Adaptive_CTL_ performed up to 1.91\(\times\) better. The minimum execution gain obtained in _Adaptive_ETL_ is 1.14 and in _Adaptive_CTL_ is 1.12 with the threads greater than 4. For number of aborts, _Adaptive_ETL_ performed up to 4.1\(\times\) better than _Lazy_ETL_ and _Adaptive_CTL_ performed up to 72\(\times\) better than _Lazy_CTL_. Compared to _Eager_, _Adaptive_ETL_ performed up to 10\(\times\) better and _Adaptive_CTL_ performed up to 124\(\times\) better.