~ /phase-1 /experiments
Phase I · Experiment design

Two knobs, six configurations.

The experiment measures how execution time changes with problem size and with the degree of parallelism. Everything else stays fixed.

N ∈ {1200, 1800, 2400}PROCS ∈ {1, 4}3 runs each18 runs total

Parameters#

Matrix size · N#

Controls the amount of computation. Tested: 1200, 1800, 2400. Purpose: see how runtime scales as the problem grows.

Processes · PROCS#

Controls the degree of parallel execution. Tested: 1 and 4, where 4 matches the VM's core count. Purpose: measure the effect of parallelization on runtime.

Configurations#

# Matrix size (N) Processes (PROCS) Rows per process Status
1 1200 1 1200 Complete
2 1200 4 300 Complete
3 1800 1 1800 Complete
4 1800 4 450 Complete
5 2400 1 2400 Complete
6 2400 4 600 Complete

Procedure#

Set the parameters#

Edit #define N and #define PROCS in matrix_fork.c.

Compile#

gcc -Wall matrix_fork.c -o matrix_fork

Run three times#

for i in {1..3}; do echo "Run $i:"; ./matrix_fork; done

Record#

Save each run's execution time and compute the average for the configuration.

Keep the environment quiet#

Make sure no other CPU-intensive processes run in the VM during measurement.

Collected data#

N PROCS Run 1 (s) Run 2 (s) Run 3 (s) Average (s)
1200 1 0.001 0.001 0.003 0.0016
1200 4 0.002 0.002 0.001 0.0016
1800 1 0.001 0.001 0.001 0.0010
1800 4 0.003 0.003 0.003 0.0030
2400 1 0.002 0.001 0.001 0.0013
2400 4 0.004 0.003 0.003 0.0033

The full analysis of this data is on the Results page.

Analysis plan#

Performance scaling#

Compare execution time against PROCS, and execution time against N.

Overhead analysis#

Estimate the cost of process creation and synchronization.

Efficiency metrics#

Compute speedup, efficiency and scalability for each matrix size.

Statistical analysis#

Calculate the standard deviation across runs to judge how consistent they are.

Hypotheses#

Scenario Expectation going in
Small N Overhead may outweigh the benefit of parallelism
Large N Parallel execution should reduce runtime
PROCS = 4 Best performance expected when processes match the 4 CPU cores
PROCS > cores Extra processes may reduce efficiency (diminishing returns)

What actually happened

The first hypothesis held at every size tested. Four processes were never faster than one. At N = 1800 and 2400 they were roughly 3× and 2.5× slower. See the Results page for the breakdown.

Tools used: Python and Excel for data analysis, and Markdown with MkDocs for documentation.