The output shows that the multi-core verification was faster than the single-core one, because 1627s < 1787.3s:
- 1 CPU/core:
User time for polyspace-c: 1787.3real, 1704.1u + 84.4s (2.6gc)
- 4 CPU/cores:
User time for polyspace-c: 1627.1real, 1729.4u + 95s (2.5gc)
This user time information is only available when the verification was done on a Linux machine. All time units are in seconds.
- The "real" part is the total time taken as perceived by the user (the wall clock time). This time includes time slices used by other processes and time the PolySpace process spent blocked (e. g. waiting for I/O to complete).
- The "u" part is the total combined CPU time that the PolySpace process spent in user-mode (outside the Kernel).
- The "s" part is the time spent by the PolySpace process in Kernel-mode (system calls / supervisor mode), including file I/O, swapping, etc.
- The "gc" part is the time spent by the Garbage Collector.
Two aspects to consider:
- If the real time is greater that the user time, it means that the rest of the time was spent doing other operations such as file I/O, etc. A possible optimization would be to use faster or larger disk drives, or to avoid using network drives, install more physical memory (RAM), etc.
- If the user time is greater than the real time on a multi-core system, it means that more than one core were involved in the verification. To better understand this, consider a fictive verification that took 10s of real time and 18s of user time. This could (fictively) mean that during the 10s of total verification time, each CPU/core spent 9s doing calculations for a total of 18s.
On a multi-core system, the speed of a verification is not expected to increase in proportion to the number of cores. The following two factors explain the physical boundaries of parallel computations:
1. Amdahl's law
2. Resource Contention in Task Parallel Problems
Refer to the Parallel Computing Toolbox documentation for the example "Resource Contention in Task Parallel Problems"
