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

On 5/19/2025 7:36 PM, Lawrence D'Oliveiro wrote:

On Mon, 19 May 2025 23:33:42 +0000, MitchAlsup1 wrote:
 

On Mon, 19 May 2025 1:13:01 +0000, Lawrence D'Oliveiro wrote:
>

Filesystem cache turnover happens in times on the order of seconds, not
milliseconds.

>
Yes, running at the latency and bandwidth of the disk/SSD subsystem not
of the DRAM system.

 It’s not really about latency, it’s just about the way the filesystem
caches are used. They quite typically take up a big chunk of the RAM on a
server, and stuff does tend to hang around in them for several seconds, to
get good cache hits. (Though on Linux that’s considered a low-priority
use, so if a regular application needs more RAM and there isn’t enough
free, then the filesystem cache will be quickly flushed as necessary to
make more available.)
 And consider that modern high-performance servers are available with
terabytes of RAM. Fill a few tens of % of that with filesystem cache, and
you see why disk caches don’t stand a chance.

The caches serve different purposes.
The OS side cache is to serve local IO requests.
The HDD cache is AFAIK more to consolidate IO requests and to prefetch stuff, in a way where the HDD knows its geometry but the PC does not, and to keep up the abstraction of 512 byte sectors on physical media that is typically no longer using 512 byte sectors.
Across multiple media types, the abstractions have converged:
   Linearly addressed array of 512 byte sectors.
Vs, say:
   Cylinder/Head/Sector geometry;
   Variable sector sizes and variable numbers of sectors per track;
   Ability for the PC to not care if it is an HDD or SSD;
   ...
You need RAM to make this work, and a few MB of HDD side cache isn't a huge cost if one would have already needed the same stuff to make the HDD work.
At this point in time, would have a 512K RAM chip be cheaper than an 8 or 16MB RAM chip?... Not really.
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.
And, then, the filesystem can continue on operating in terms of an abstract device without needing to be overly concerned with the physical geometry of the underlying HDD.
Well, or sometimes, the filesystems try to be too clever and actually make things worse.
Say, for example, if the FS tries to allocate files such that each starts on a multiple of 32K (with a 4K cluster size), but then C source files are often not so effective when spaced on multiples of 32K, and if it goes back later and reclaims these intermediate clusters, then the original files are not particularly densely packed, and a bunch of other random files are shoved between, ... Leading to worse performance than have the files simply been densely packed end-to-end in the first place.
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.
Well, and if one has lots of files of this sort, often a 1K cluster size makes sense as less space will be wasted on partial blocks (in the absence of end-packing). But, then one also wants to have moderately compact directory entries and inodes.
Say:
   256 byte inode is good;
   1024 byte inode (cough, "MFT Entry") is waste;
   64 byte directory entry is good;
     Like, ~ 95..99% of filenames do not exceed 48 characters.
     Can special-case those that need more.
   256 to 512 bytes is waste;
     More so with the pointlessness of UTF-16 filenames.
     Better to optimize for the 99% case here, IMO.
     Vs, always provisioning for the worst case.
   ...
Though, does depend some on the relative cost though between constant overhead data, and file payload.
...