## 5 IO Data Management and Data Sharing
### Distributed SQL Databases with RPC
#### 5.1.1. Replicated Data Bases and Tables
The reason is unknown, but it is expected that L3 data cache flooding by increased matrix data size is invalidated by the decreasing execution time beyond \(N\) > 1000. It may be that the memory garbage collection of the VM (Google V8) has a relevant impact, although there is no major data allocation during the test (all input, intermediate, and output matrix data were allocated before computation). Up to \(N\) = 512, the computational time using the JS VM CPU is only about two times slower than an optimized native code (C) implementation. The pipelined CNN light computation shows similar results for both web and shell workers (host platforms with integrated Intel GPU) with a typical speeding-up of about 3-4. For CPU computations this is irrelevant; the GPU computation shows a slight speeding-up if the computation is performed repeatedly (\(R\) > 1) in a loop, without any intermediate CPU-GPU memory transfers (bottom figure, second-right table), which is typical for ML training processes. Figure 7: **(Top)** WorkBook worker/WebGL; **(bottom)** WorkShell worker/OpenGL: performance analysis of an N \(\times\) N matrix multiplication, using Vanilla JS and GPU transpiled kernel functions (Integrated Intel GPU). This analysis shows clearly that the deployment of GPGPU for medium data-path parallelism is only of benefit for large matrix sizes and matrix loop iterations. In particular, the V8 engine already poses a high nearly native code performance for compact and nested loop iterations over matrix data. This observation is in accordance with the analysis performed in [16]. ## 8 Case Studies

### Test Framework

The evaluation of the PSciLab software framework, with its unified processing and communication architecture, in terms of speeding up and scaling up by parallel processing, is performed using different hardware and software platforms, as summarized in Table 3. Both shell and web worker classes are addressed. To compare the different hardware architectures and systems with each other, a dhrystone benchmark is performed. The dhrystone benchmark combines different typical high-level operations: object allocation and release, function calls, array and string operations, and numerics. The original dhrystone was adapted to JavaScript (from an already existing dhrystone adaptation for Python). The (js)dhrystone results are important key measures for the pool server to estimate the computational power of a host and to balance worker distribution. Another important key measure is the starting-up time of a new worker. Finally, computational efficiency is computed for each example of computer architecture:

\[\eta=\frac{k\text{j}\text{s}\text{d}\text{hrystones}\cdot\text{NC}}{\text{ TDP}}\left[\frac{1}{W\text{s}}\right] \tag{3}\]

Figure 8: **(Top) WorkBook worker/WebGL; (bottom) WorkShell worker/OpenGL: performance analysis of a data flow pipeline with 1 matrix kernel convolution, a fully connected perceptron layer merging the convoluted matrix with the application of a sigmoid function, and a second, fully connected perceptron layer (R: number of loop iterations). **

The thermal dissipation power (TDP) is related to the CPU power consumption and offers another key measure to assess the computer system power for numerical computations. _NC_ is the number of processor cores.