5 ms·
So after the last blog post by The Author which mainly showed The Author's lack of understanding, we have another article from The Author highlighting that he d
by dom0 10y ago
So after the last blog post by The Author which mainly showed The Author's lack of understanding, we have another article from The Author highlighting that he does indeed not understand things he writes blog posts about (incorrect rationale and assumptions about 128 KiB block size being optimal, no readahead on virtual device files, and of course not mentioning any of the FD splicing alternatives in a post titled "Efficient ..." or any of the approaches involving memory mappings and explicit prefetching on said mappings).
I don't want to be overly extremely dismissive or arrogant here, but this post pretty much boils down to "128 KiB is optimal because that number appears somewhere else, too, and that other spot even has somehow something to do with I/O".
- akanet 10y agoWhile your criticisms about what the author's explanation lacks or does not consider are appreciated, I think this is a wonderful opportunity for you to put forth your own understanding! I know very little about the topic and thus found the article interesting. I would happily learn more.
- ars 10y agoLarger blocksizes are faster, but take more memory and interleave badly with other tasks since they are all-or-nothing. A large block can take a while and nothing else can read or write while it's running. That's about it. You want a blocksize sized so that it takes around 10 ms to write to disk. So around 128K to 1MB, depending on the underlying hardware.
- dredmorbius 10y agoYour 2nd paragraph's characterisation doesn't correspond to the article, which specifically cites empirical testing of multiple blocksizes and a demonstration of optimal performance at 128 KB: "The author of this file did a benchmark using dd if=/dev/zero of=/dev/null with different values of the bs (block size) parameter. On a wide variety of systems, including older Intel CPUs, modern high-end Intel CPUs, and even an IBM POWER7 CPU, a 128 KB block size is fastest. I used gnuplot to graph these results, shown below (higher transfer rate is better). The different symbols represent different system configurations."
- ars 10y ago> which specifically cites empirical testing Are you serious? He tested /dev/zero to /dev/null and assumed that was somehow related to readahead of a hard disk.
- dredmorbius 10y agoPoint. But it does show that, abstracting away disk IO itself, the system bus and processor handle IO best at 128 KB blocksizes. It's easy enough to start substituting in disk specifications for read or write and continue the experiment.
- ars 10y agoNo, it does not show that. /dev/zero and /dev/null are special. If you want to abstract away disk IO then use a memory drive.