## 3 Parallel ARIA Implementation
### Parallel ARIA Implementation on GPU
\begin{table}
\begin{tabular}{c c c c} \hline
**Imple.** & **Target** & **Parallel** & **CPB** \\ \hline [PERSON] et al. [14] & 32-bit ARM Cortex-M3 & 1-PT & 147 \\ [PERSON] et al. [15] & 32-bit RISC-V HiFive1 rev b & 1-PT & 295 \\ Reference C & 64-bit ARMv8 Apple M1 & 1-PT & 4.77 \\ This work & 64-bit ARMv8 Apple M1 & 4-PT & 1.73 \\ This work & 64-bit ARMv8 Apple M1 & 16-PT & 0.57 \\ This work & 64-bit ARMv8 A12 Bionic & 4-PT & 2.17 \\ This work & 64-bit ARMv8 A12 Bionic & 16-PT & 0.96 \\ \hline \end{tabular}
\end{table} 
Table 2: Performance comparison of implementation of the ARIA block cipher. As shown in Table 1, it can be seen that the use of shared memory improves computation and memory throughput and, as a result, shortens the kernel operation time. In terms of kernel execution time, performance is improved by 1.08\(\times\) using shared memory. However, we found that implementations of extending Sbox tables to avoid bank conflicts performed worse than using global memory. While the size of the bank is 32, it seems that it cannot prevent a complete bank collision, because only four copies were copied. To analyze this in more detail, we compare the performance according to the number of table copies. We use a fixed number of blocks and threads as above (block: 1024 \(\times\) 32, thread: 256). The performance results are shown in Table 4.

Due to the size limit of shared memory, up to 12 tables can be copied. As a result of the measurement, it was confirmed that the higher the number of copies of the table, the lower the performance. When performing front table expansions ([4][256]), the increased number of copies slowed down memory throughput, resulting in poor performance. Increasing the number of copies only increases the number of copies of the table from global memory to shared memory and degrades performance because the bank conflicts cannot be resolved. When performing back table expansions ([256][4]), the increased number of copies slowed down compute throughput, resulting in poor performance. An increase in bank collisions is considered to be the cause of a decrease in the computational throughput. As a result, it is inefficient to apply this technique when it is impossible to copy as much as the bank size. Next, we checked the performance comparison according to the number of blocks, which is one of the factors affecting performance. In this case, we fixed only the number of threads (256) and increased the number of blocks during the measurement. We did not compare the performance of table extension implementations, we only compared the performance of global and shared memory implementations, because we saw above that table expansion is inefficient. The performance results are shown in Table 5. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Type** & **Duration (ms)** & **C. Throughput (\%)** & **D. Throughput (\%)** & **Bank Conflicts** \\ \hline Sbox[4][256] & 8.15 & 58.43 & 98.52 & 123,863,597 \\ Sbox[8][256] & 8.57 & 59.21 & 96.70 & 126,228,907 \\ Sbox[12][256] & 9.16 & 58.77 & 91.87 & 126,287,694 \\ Sbox[256][4] & 8.14 & 58.42 & 98.94 & 124,919,451 \\ Sbox[256][8] & 9.50 & 53.32 & 98.73 & 156,685,446 \\ Sbox[256][12] & 9.93 & 54.18 & 94.59 & 152,467,045 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Performance by number of Sbox table copies (C.: compute, M.: memory, block: 1024 \(\times\) 32, thread: 256). In this case, when the same memory type is used, the kernel operation time (duration) cannot be compared because the input data increases as the number of blocks increases. However, the kernel operation time is also included for comparison according to memory types. In fact, increasing the number of blocks did not affect performance, but here we can see that the number of blocks does not affect performance (in implementation of ARIA block cipher). Additionally, we can reaffirm that using shared memory can help improve performance. Finally, we compare the performance according to the number of threads.