BW_FILE_RD(8)

πŸ’– BW_FILE_RD(8) β€” the LMBENCH girlies' guide to timing a file read πŸ’–

okay bestie, welcome to bw_file_rd</b>, section 8 of the LMBENCH manuals, and it's literally just "how fast can we read this file and add up the numbers" and honestly? iconic. ✨


🌸 NAME 🌸

bw_file_rd β€” time the reading and summing of a file πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

bw_file_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]
size file

✨ DESCRIPTION ✨

so what this does is time the read of the specified file in 64KB blocks. every block gets summed up as a series of 4 byte integers in an unrolled loop (yes, unrolled, she's extra like that πŸ’…). results come out reported in megabytes read per second. slay.

here's the lil catch though: the data is not accessed in the user program. the benchmark is fully relying on the operating system's read interface to have actually moved the data, fr fr. so systems that implement page flipping may fool this benchmark. not saying they will, but like… they can. πŸ™ˆ

the vibe is that this benchmark is intended to be used on a file that is in memory β€” i.e. it's a reread benchmark. if you wanna do other file benchmarking, that's a whole different thing and you should go hang out with lmdd(8) instead. 🫢

and the size specification? it may end with k or m, which means kilobytes (* 1024) or megabytes (* 1024 * 1024). periodt. πŸ’–


πŸ“Š OUTPUT πŸ“Š

the output format is "%0.2f %.2f\n", giving you megabytes and then megabytes_per_second. so like:

8.00 25.33

no notes, she's clear, she's concise, she ate. πŸ‘‘


🧠 MEMORY UTILIZATION 🧠

okay this part is lowkey the drama of the whole page. this benchmark can move up to three times the requested memory. let me explain, bestie:

most Unix systems implement the read system call as a bcopy from kernel space to user space. and bcopy will use 2-3 times as much memory bandwidth, because there's one read from the source and a write to the destination. that write usually results in a cache line read and then a write back of the cache line at some later point. it's giving extra steps, honestly. πŸ’€

and get this β€” memory utilization might be reduced by 1/3 if the processor architecture implemented "load cache line" and "store cache line" instructions (as well as "getcachelinesize"). so yeah, hardware girlies, that's your moment. ⭐


🌈 ACKNOWLEDGEMENT 🌈

funding for the development of this tool was provided by Sun Microsystems Computer Corporation. ty for your service πŸ«‘πŸ’–


πŸ‘€ SEE ALSO πŸ‘€


πŸŽ€ AUTHOR πŸŽ€

Carl Staelin and Larry McVoy πŸ’œ

comments, suggestions, and bug reports are always welcome. like genuinely, slide into the inbox, they want to hear from you bestie. 😭🫢


and that's the whole page!! written by (c)1994 Larry McVoy, with the $Date$ placeholder doing its lil thing, from the LMBENCH source and dated whenever that date says, in section 8 of the manual. bye bestie, go benchmark something responsibly πŸ’…βœ¨πŸŒΈ