~ /phase-1 /report
Phase I · Report

The Phase I report, in full.

The complete write-up of the process-based experiment, embedded below. Open it as a standalone page or download the PDF.

HTML + PDFProcess-based matrix multiplication
Open full HTML report Download PDF

Embedded report#

phase-1/report-full.html Open in new tab

Discussion#

In theory, parallel processes should cut execution time by dividing the work across cores. In Phase I, for matrix sizes 1200 to 2400, four processes had little or negative effect.

Process creation overhead#

Creating processes with fork() adds overhead that can dominate short runs.

Synchronization cost#

The parent waits for every child with wait(), so total time includes coordination.

Problem-size threshold#

At these sizes, the computation may be too small to pay back the overhead.

For much larger matrices, such as N = 10000, gains become more likely, because computation time would dominate process overhead.

Implications for parallel programming#

  • Parallelism improves performance only when the workload is larger than the overhead.
  • Using every available core does not guarantee better performance.
  • There is a minimum problem size below which parallelization does not pay off.

Experimental limitations#

  • Virtualization overhead: the VM layer can add performance penalties.
  • ARM64 architecture: performance characteristics differ from x86 systems.
  • Initialization: random initialization adds work that cannot run in parallel.

Conclusion#

In Phase I we:

  • set up Ubuntu Linux (24.04.3 LTS, ARM64) in a virtual machine,
  • installed GCC and the development tools,
  • compiled and ran the provided program,
  • tested 6 configurations and recorded every run.

Key findings

  • Parallel processes gave no meaningful speedup at these sizes.
  • Process creation and synchronization overhead most likely dominated the runtime.
  • Larger problem sizes are probably needed to see a clear benefit.

Future work#

Thread-based parallelism#

Evaluate a pthread implementation and compare its overhead.

Better work distribution#

Try other decomposition strategies for better load balance.

Less overhead#

Investigate process pooling or reduced synchronization.

Larger problems#

Test matrices beyond 2400 × 2400 to find where parallelism starts to pay off.

Comparative benchmarks#

Compare against sequential and optimized baselines to quantify the overhead.