## 4 Performance Evaluation in Edge Scenarios
### CPU-Intensive Workload  
The Native-mode Benchmark (NBench) is a common test suite used to assess CPU performance, primarily focusing on the computational speed, floating-point operations and memory system efficiency of a computer. The NBench results are measured by the number of test iterations completed within 1 s. The more iterations are completed, the higher the efficiency. Taking the native Linux test results as the baseline, the performance of SGX implementations are illustrated in Figure 2.  
Overall, the implementation based on the SGX SDK has the worst performance, while Gramine performs the best. The performance of Occlum is similar to that of Gramine, and there is almost no difference between the virtual and native environments. The implementation based on the SGX SDK incurs significant context-switching overhead due to frequent enclave transitions, which leads to significant performance overhead. In the FOURIER test, it achieves only about 30% of the native performance. For the two LibOS-based approaches, Gramine performs well across all tests, with a minimum performance of about 80% of native performance. Occlum excels in numerical sorting, bitwise operations and LU decomposition, but in other tests, its performance is approximately 40% to 60% of the native performance. This is because Occlum's design is more oriented towards multi-process environments, allowing multiple processes to coexist within a single enclave, whereas Gramine excels in single-threaded processing capabilities.  
Separately, in the numerical sorting task, all four SGX implementations perform well, with performance being close to that of native Linux. This is due to the use of heap  
\begin{table}
\begin{tabular}{l c} \hline \hline \multicolumn{2}{c}{**Hardware Environment**} \\ \hline CPU: Xeon(R) W-1250 CPU, 4.70 GHz & DRAM: 16 GB \\ \hline CPUs: 1 Socket, 12 cores \\ \hline L1: 384 KB, L2: 1536 KB, L3: 12 MB \\ \hline \multicolumn{2}{c}{**System Settings**} \\ \hline Linux kernel: 6.6.8-060608-generic & GCC: 9.4.0 \\ \hline OS: Ubuntu 20.04 & Architecture: x86\_64 \\ \hline \multicolumn{2}{c}{**Intel SGX SDK**} \\ \hline Version: 2.22 & PRM:128 MB \\ \hline \multicolumn{2}{c}{**Gramine**} \\ \hline Version: 1.6 & Enclave size: 256 MB \\ \hline Max\_threads: 4 & \\ \hline \multicolumn{2}{c}{**Occlum**} \\ \hline Version: 0.26.4 & User\_Space\_Size: 300 MB \\ \hline Max\_threads: 32 & \\ \hline \hline \end{tabular}
\end{table}
Table 3: System configuration.  
Figure 2: CPU-intensive workload.  
sort in the sorting task, and the small amount of numbers to be sorted in each group, which avoids the issue of insufficient enclave capacity. As a purely computational task, the performance of all SGX implementations is similar. In the bitwise operation test, LibOS-based approaches achieve performance close to native, while the SGX SDK shows a significant performance decline. In the floating-point computation tests, Occlum shows a performance decline relative to Gramine, indicating that Occlum is weaker in floating-point calculations. In purely CPU-intensive tasks, both Gramine and Occlum exhibit minimal performance degradation, while the SGX SDK experiences a notable performance decline. In edge intelligence scenarios, if using SGX SDK, it is essential to make efficient use of the limited memory space within the enclave and minimize the number of enclave transitions to reduce performance overhead.