Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

On Tue, 20 May 2025 00:16:44 -0500, BGB wrote:

Also the SATA interface is technically faster and has a higher bandwidth
than it can actually read stuff from the HDD itself, so if the HDD's
cache can do *anything* (in terms of prefetch and allowing IO requests
to be completed more quickly) it is still a win.

But that depends on the disk cache having something useful in it. Which,
as we have seen from its place in the hierarchy and the basic statistics
of cache operation, is pretty unlikely.

The cost/benefit balance is negative: it contributes essentially nothing
to performance, while detracting to some extent from reliability.

Well, say, because the FS designers seem to casually assume smaller
numbers of multi-MB files, rather than people filling the drive with
millions of files most of which being kB sized.

Filesystem designers have solutions for that. Look up “tail-packing”.

This is why drive designers should not be second-guessing OS filesystem
designers.

The caches serve different purposes.

I think drive designers suffer from an inferiority complex: they know
their product is right at the bottom of the performance hierarchy, so they
try to come up with ways to make them seem faster than they are, instead
of concentrating on their number one job, which is ensuring the integrity
of the data they’re entrusted with storing.