PAR_MEM(8)

🌸 NAME 🌸

okay bestie, meet par_mem — the memory parallelism benchmark 💅 she's part of the LMBENCH crew, and she lives in section 8 of the manual (yep, the sysadmin girlies), so her full government name is par_mem(8). 🎀

---

📜 SYNOPSIS 📜

par_mem [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

so the synopsis ships four little knobs, and since the page doesn't spill extra tea about them beyond this line, here they are exactly as written, no notes, no embellishment:

• -L <line size> — the line size one 🧵
• -M <len> — the len one 📏
• -W <warmups> — the warmups one 🔥
• -N <repetitions> — the repetitions one 🔁

---

✨ DESCRIPTION ✨

okay so par_mem measures the available parallelism in the memory hierarchy, up to len bytes. 🦋

here's the vibe: modern processors can often service multiple memory requests in parallel, while older processors typically blocked on LOAD instructions and had no available parallelism at all — other than the parallelism that cache prefetching provides, anyway. and because the available parallelism is often a function of where the data sits in the memory hierarchy, she measures it at a whole variety of points. iconic behavior honestly. 👑

🧚 how she actually does it 🧚

to measure the available parallelism, par_mem runs a variety of experiments at each memory size — one for each level of parallelism. the recipe:

1. she builds a pointer chain of the desired length. 🔗
2. then she creates an array of pointers which point to chain entries that are evenly spaced across the chain.
3. then she starts running the pointers forward through the chain in parallel. 🏃‍♀️🏃‍♀️
4. from that she can measure the average memory latency for each level of parallelism, and the available parallelism is:

minimum average memory latency for parallelism 1 ÷ average memory latency across all levels of available parallelism 🧮

no cap, that's the whole formula, bestie.

🫶 the parallelism-2 inner loop, for the visual learners 🫶

for example, the inner loop which measures parallelism 2 would look something like:

for (i = 0; i < N; ++i) {      p0 = (char **)*p0;      p1 = (char **)*p1; }

in a for loop (the overhead of the for loop is not significant; the loop is an unrolled loop 100 loads long). 🍓

so like, in this case: if the hardware can process two LOAD operations in parallel, then the overall latency of the loop should be equivalent to that of a single pointer chain, so the measured parallelism would be roughly two. 😌✨

but if the hardware can only process a single LOAD operation at once, or if there's (significant) resource contention between the two LOAD operations, then the loop will be much slower than a loop with a single pointer chain — so the measured parallelism will be less than two, and probably no smaller than one. 💀 it's giving "the hardware said no."

---

📊 OUTPUT 📊

the output format is intended as input to xgraph or some similar program (they use a perl script that produces pic input, fyi). 🎨

there's a set of data produced for each stride. and:

• the data set title is the stride size 🏷️
• the data points are the array size in megabytes (that's a floating point value, bestie) 📈
• plus the load latency over all points in that array ⏱️

---

👀 SEE ALSO 👀

• lmbench(8)
• line(8)
• cache(8)
• tlb(8)
• par_ops(8)

go read the whole squad, they're all mother. 💜

---

🫶 AUTHOR 🫶

Carl Staelin and Larry McVoy — the icons who made her. 👑

and fr fr: Comments, suggestions, and bug reports are always welcome. 🙈 they want to hear from you, don't be shy.

---

🌈 that's the whole page, bestie — go benchmark something and slay. periodt. 💅✨

(c)2000 Carl Staelin and Larry McVoy — $Date$ 🎀 this page is PAR_MEM(8), brought to you by the LMBENCH girlies. bye bestie! 🦋💖