## 4 Results  
### Processing Time  
The processing time is one of the most critical variables that define the efficiency of computing systems. The faster a problem is solved, the more effective the decision-making process. In AI applications, where real-time decision-making is often a key requirement, this factor is crucial. Table 4 presents the processing or training times recorded on the three computing infrastructures used in this study for image classification using the three selected datasets. This comparison provides valuable insights into the relative performance of the distributed training strategies implemented with DDP PyTorch and Distributed TensorFlow Multi-WorkerMirroredStrategy, evaluated using different hardware configurations. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Infrastructure** & **Dataset** & \
\begin{tabular}{c} **Distributed Data** \\ **Parallel PyTorch** \\ \end{tabular} &
\begin{tabular}{c} **Distributed** \\ **Tensorflow** \\ \end{tabular} \\ \hline \hline \multirow{4}{*}{Workstation} & Cloud & 4 h 12 m 22 s & 5 h 18 m 18 s \\  & MSLD & 12 m 14 s & 19 m 36 s \\ \cline{1-1}  & CIFAR 100 & 24 m 8 s & 37 m 41 s \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Processing time in computing infrastructure. As shown, in most experiments, the PyTorch DDP implementation achieved the best processing times compared to Distributed TensorFlow MultiWorkerMirroredStrategy, especially in environments where the number of available GPUs was limited. Specifically, on the LSDS-HPC infrastructure proposed in this study, the 38-Cloud and MSLD datasets recorded the lowest training times. However, for the CIFAR-100 dataset, Workstation achieved the best performance in terms of processing time. As mentioned in Section 3.3.4, one key reason for the lower processing times observed in the LSDS-HPC infrastructure is that training was performed over 17 epochs, unlike Google Colab and Workstation, where 50 epochs were used for training. Although this difference has been previously justified, it is worth emphasizing again, as it directly influences performance outcomes and reflects the trade-offs inherent to data parallelism operations in distributed training settings. Furthermore, it is widely accepted and verified in our experiments that running all 50 epochs of each dataset on the LSDS-HPC significantly increases the time processing, as the training is executed as if on a single node. The synchronization provided by DDP and MultiWorkerMirroredStrategy helps stabilize the training process across multiple nodes and improve convergence, thus enforcing the basic principles of data parallelism. An important limitation identified in the experiment was that when entering data from the 38-Cloud dataset, memory overflow occurred, and the libraries threw errors. To address this, a resize factor was applied to the dataset to reduce the batch size and allow the distributed training to run smoothly on the LSDS-HPC. Empirical speedup can be calculated using Equation (2), where \(T_{s}\) represents the processing time (in seconds) for training on a single node with respect to \(T_{p}\), which is the processing time (in seconds) using multiple nodes or the DS. As shown in Table 5, the empirical speedup highlights how the training performance improves (or degrades) when transitioning from a single-node environment (Workstation or Google Colab) to a multi-node infrastructure (LSDS-HPC). The highest speedup was obtained when training ResNet50 with the CIFAR-100 dataset on Google Colaboratory using Distributed TensorFlow, reaching a 6.74\(\times\) increase in performance. In contrast, the lowest speedup (0.03\(\times\)) was also observed on Google Colab using PyTorch DDP for the same dataset, suggesting that the performance gains vary significantly depending on both the framework and the specific workload characteristics.