A two-phase study of parallelism on real hardware. Phase I splits
matrix multiplication across Linux processes with
fork() and wait(). Phase II splits a sum of
cubes across Java threads. Each configuration was timed, compared with
its baseline and explained.
The project asks a simple question: does splitting work across more processes or threads make a program faster? We answered it twice, with two operating system mechanisms, on two machines.
In Phase I, a C program multiplied matrices of size
1200 to 2400 inside an Ubuntu VM, using one process or four. With four
processes the program was never faster, and at N = 1800 it was
3× slower. At these sizes, fork(),
scheduling and wait() cost more than the parallel work
saved.
In Phase II, a Java program summed the cubes of 1,000,000 integers using 1, 2, 4, 6 and 8 threads on an Apple M2. Two threads were 15% slower than one. Eight threads were 5.79× faster.
Each phase has its own setup, method, raw data and report. Pick one to explore.
C and GCC on Ubuntu 24.04 (ARM64) in a UTM virtual machine with 4
cores and 4 GB RAM. Rows of the matrix are divided among child
processes created with fork().
Java on OpenJDK 25 on an 8-core Apple M2. The array is split into
contiguous chunks, and each Summer thread returns a
partial sum that is combined after join().
Pick a thread count. The array is divided exactly as
parallelSum() divides it, and the timer runs for a time
proportional to the measured average for that configuration.
Speedup is T(1) / T(n). The dashed line shows ideal linear scaling. The measured curve dips below 1× at two threads, stays near 1× at four, then climbs steeply. The gains came only once there were enough threads to outweigh the cost of creating and joining them.
Each fork() creates a whole new process with its own
copy-on-write address space, and the parent must
wait() for every child. With runtimes of about a
millisecond, that fixed cost was larger than the matrix work it split
up. At N = 1800 and 2400, the speedup fell below 0.4×.
Each phase had clear owners. Code, measurement, metrics, graphs and the report were passed from one person to the next. Select a member to see what they did.
Both phase briefs, the submission checklist and the 100-mark scheme.
OpenUTM, Ubuntu 24.04 ARM64, 4 cores and 4 GB, with screenshots of every step.
OpenThe full matrix_fork.c source, how to compile it and how to change N and PROCS.
OpenControlled conditions, timing method and the questions the analysis answers.
OpenWho did what, in what order, with every task tracked to completion.
OpenA searchable reference of the Linux, GCC and Git commands used in the project.
OpenSpeedup, overhead, fork(), join() and every other term, defined.
OpenAn interactive VS Code and Git guide for contributing to the repository.
OpenBoth reports cover the method, tables, graphs and discussion. The repository contains the source and all documentation.