User/style guide should be written to notify users of how parallelism changes the optimal software structure (as now they build Technical Debt into their systems).
Submitted by Kristof Szabados
Link to original bug (#570599)
Description
While the Designer plugin was mainly doing its analysis in a single-threaded way, the traditional way of organizing code to minimize duplication was kind of optimal. But since this semantic checking was made massively parallel, and both the C and Java side build processes also use massive parallelism (+now hardware with several CPU cores became the norm) this has changed.
When a single thread is processing the source code it makes sense to minimize the size of the source code, by merging otherwise duplicated elements into central modules. Creating "Types" modules is a good example: by moving all of the types from the test system into a single module, all types based code duplication can be eliminated, code size reduced ... thus leading to faster analysis and build times.
With massive parallelism, this changes. In this structure moving all types into a single module still eliminates code duplication, but also creates a central point:
- whose processing can not be parallelized
- on which most other modules will depend on ... aka. their analysis has to wait. Effectively making analysis and build processes take longer than necessary.
In a parallel architecture, it is better to allow some level of code duplication, in order to speed up the process, if that means that several threads can work on the code at the same time. As in such a case the amount of work to be done can be better distributed ... aka. the more CPU cores are involved the faster the build will finish overall. (please note, this does mean that there will be more work done overall, but the system could still finish faster).
Example: Let's have a system where theoretically 3 independent features use overlapping types. types1 <- feature1 types2 <- feature2 types3 <- feature3
When the types are merged into a single module that decreases the overall work to be done but also forces single-threaded processing. In such a setup, the processing of the code related to the features can not start until the processing of the central types module is no finished. In a setup like this: types <- feature1 types <- feature2 types <- feature3 The code of types has to be processed first (utilizing only a single core) and only after it can the parallel processing of the features start.
However, if these types modules are kept separate, they can be analyzed in parallel from the beginning. please note, that this benefit comes at least 2 places:
- if the types only overlap and are not perfect copies, each individual module will be shorter, than the merged one. Decreasing the amount of work needed to be processed individually.
- Being able to utilize 3 cores to process 3 (smaller) files in parallel, should always result in reaching the end of processing earlier.
This should be communicated to the users. As right now, if they still follow program structuring methods that were optimal earlier, they are creating suboptimal systems, that slow down their development.
Version: 7.2.0