## 5 Experimental Evaluation and Results
### Experimental Setup  
The experiments were conducted on a server equipped with an Intel Xeon(r) Gold 5218 CPU(r) running at 2.30 GHz. The server featured 32 cores (64 hyper threads) and cache sizes of 32 KB for both the data and instruction cache, 1024 KB for the L2 cache, and 22,528 KB for the L3 cache. It was also equipped with 256 GB of Optane DCPMM (2 \(\times\) 128 GB) DIMMs in memory mode and 32 GB of DDR4 DRAM. The server ran Ubuntu server 18.04.4 LTS with kernel version 5.4.9-47-generic. The persistent memory development was facilitated using PMDK 1.8, and all the code was compiled using GCC 9.0 as indicated in Table 1.  
Experiment parameters: These were carefully selected to ensure a fair comparison with prior works such as CCEH [14] and Dash [18], which also employ dynamic hashing on persistent memory (PM). To address data issues, threads were pinned to their respective physical cores in the multicore environment. Given that all the compared schemes utilize extendible hashing, similar setups were used to obtain reliable and comparable results. Hashing schemes like level hashing [15], which do not utilize the PM physical device for evaluation, were not considered in this scheme. Additionally, previous studies concluded that CCEH [14] outperformed these schemes in DRAM implementation. For a fair comparison, the experiment parameters were set accordingly. CCEH uses a segment size of 16 KB, a bucket size limited to 64 bytes, and a probing length of four. Dash, on the other hand, employs a bucket size of 256 bytes (equivalent to four cache lines) and a segment size of 16 KB. Therefore, in the case of ESH, we chose a bucket size of 256 bytes and a segment size of 1 KB, with a probing distance of four. In prior work on CCEH, an increase in performance was observed as the segment size increased. This is attributed to the larger segment size allowing more data to be stored in memory and reducing the frequency of probing. In ESH, each bucket stores 28 key-value pairs of 8 bytes each, totaling 224 bytes, along with 32 bytes of metadata. A single segment accommodates four buckets. This configuration was chosen to effectively utilize the advantages of the Optane persistent memory buffer, which issues a 256-byte write block. Although the previous CCEH [14] scheme utilized a 64-byte bucket size to fit within a cache line, this was limited by the PMEM write block. By extending the bucket size to a 256-byte block, we achieve a balance where two blocks can be efficiently utilized. As the data size increases, the size of the hashing table also increases, resulting in a higher number of directory entries and segments following the extendible hashing technique. The performance and effectiveness of the hashing scheme were assessed through a series of benchmarks designed to simulate realistic workloads. These benchmarks were used to test the scheme's performance under specific loads and collect diagnostic information to identify and address potential bottlenecks. The benchmarking tools employed evaluated various hashing operations, including insertion, search, and update operations. By comparing the results of these benchmarks with those of other schemes, the scheme's performance could be assessed and its competitiveness evaluated. \begin{table}
\begin{tabular}{c c} \hline \hline
**Setup Used** & **Specifications** \\ \hline Server & Intel Xeon®Gold 5218 \\  & Processor—Intel CPU® 2.30 GHz 32 cores (64 hyper threads) \\  & 32 GB DDR4 RAM \\  & 256 GB Optane DCPMM (2 \(\times\) 128 GB) DIMMs \\ \hline OS & Ubuntu server 18.04 LTS with Kernel 5.4.9-47-generic \\ \hline Platform & PMDK 1.8 and GCC 9.0 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Experimental setup. To conduct the experiment, an initial data load of 10 million records was pre-loaded using the GCC file that defines Hash_bytes. This file utilizes the MurmurHashUnaligned primitive [54], which is a public domain hash function known for its fast and high-quality hashing capabilities.