## 3 Technology Background
### Fun
These results show that, for the same number of hardware accelerators, it is preferable to favor scalability in the number of nodes rather than in the number of accelerators per node, since the per-node memory-management overhead is slightly larger than the internode communication overhead. Notice that execution times when using one node, a scenario that should be similar to the one reported in the previous section, are slightly larger due to the overhead generated by the communication API. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline \multirow{2}{*}{\(\mathbf{Nz\times Ny\times Nx}\)} & \multirow{2}{*}{\#Nodes} & \multicolumn{4}{c}{**Execution Time (s)**} \\ \cline{3-6}  & & **1 acc** & **2 accs** & **3 accs** & **4 accs** \\ \hline \multirow{4}{*}{\(256\times 128\times 128\)} & 1 & 1.18 (1\(\times\)) & 0.84 (1.4\(\times\)) & 0.73 (1.6\(\times\)) & 0.67 (1.8\(\times\)) \\  & 2 & 0.72 (1.6\(\times\)) & 0.56 (2.1\(\times\)) & 0.49 (2.4\(\times\)) & 0.44 (2.7\(\times\)) \\ \cline{1-1}  & 4 & 0.46 (2.6\(\times\)) & 0.41 (2.9\(\times\)) & 0.37 (3.2\(\times\)) & 0.34 (3.5\(\times\)) \\ \cline{1-1}  & 8 & 0.38 (3.1\(\times\)) & 0.31 (3.8\(\times\)) & 0.29 (4.1\(\times\)) & 0.27 (4.4\(\times\)) \\ \hline \multirow{4}{*}{\(256\times 256\times 256\)} & 1 & 4.72 (1\(\times\)) & 3.35 (1.4\(\times\)) & 2.87 (1.6\(\times\)) & 2.66 (1.8\(\times\)) \\  & 2 & 2.83 (1.7\(\times\)) & 2.12 (2.2\(\times\)) & 1.88 (2.5\(\times\)) & 1.85 (2.6\(\times\)) \\ \cline{1-1}  & 4 & 1.99 (2.4\(\times\)) & 1.51 (3.1\(\times\)) & 1.38 (3.4\(\times\)) & 1.45 (3.3\(\times\)) \\ \cline{1-1}  & 8 & 1.4 (3.4\(\times\)) & 1.35 (3.5\(\times\)) & 1.15 (4.1\(\times\)) & 1.11 (4.3\(\times\)) \\ \hline \multirow{4}{*}{\(256\times 512\times 512\)} & 1 & 49.04 (1\(\times\)) & 30.67 (1.6\(\times\)) & 24.29 (2\(\times\)) & 21.14 (2.3\(\times\)) \\ \cline{1-1}  & 2 & 25.88 (1.9\(\times\)) & 16.9 (2.9\(\times\)) & 14.17 (3.5\(\times\)) & 12.37 (4\(\times\)) \\ \cline{1-1}  & 4 & 14.69 (3.3\(\times\)) & 10.18 (4.8\(\times\)) & 8.56 (5.7\(\times\)) & 7.8 (6.3\(\times\)) \\ \cline{1-1}  & 8 & 9.12 (5.4\(\times\)) & 6.78 (7.2\(\times\)) & 6.52 (7.5\(\times\)) & 5.55 (8.8\(\times\)) \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Execution performance—ARTICo3 (multiple nodes @ 166.67 MHz). Figure 4: ARTICo3-based multi-FPGA computing cluster. This high-performance embedded computing setup features eight MicroZed boards with a XC7Z020-1 CLG400C device. The second set of tests performed with the multi-FPGA setup has been devised with a twofold objective: on the one hand, to compare the hardware-accelerated solution with a software-based alternative; on the other hand, to quantify the communication overheads in the system. Using MPI terminology, the hardware version uses one slave process with up to four ARTICo3 accelerators per node (with a master process running in one of the nodes), while the software version uses two slave processes per node to maximize the number of processing elements working potentially in parallel (although one node has the master process and one slave process instead). In addition, processing is carried out completely in the slave processes for the hardware version, while for the software version the master process also performs computations (again, to maximize the number of processing elements working potentially in parallel, and perform a fairer comparison against the hardware-based implementation). As a result, total execution times in Table 11 equal communication time plus processing time for software, but not for hardware (ARTICo3 finishes processing in each slave while the master is still sending or receiving data through the network). This phenomenon resembles the memory-bounded behavior in single-node deployments, where the memory bandwidth sets the maximum performance boundary for accelerators where DMA-enabled data transfers are more time-consuming than actual kernel execution. Results from Table 11 show that, for small hyperspectral images, the ARTICo3-based solution is slower than the software-based alternative.