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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Think of what a cache is for in the first place. The only reason they work
is because of the “principle of locality”. This can also be expressed as
saying that typical patterns of data access by application programs follow
a Pareto distribution, less formally known by monikers like the “80/20
rule” or the “90/10 rule”.

IBM "added" full-track "-13" cache to 3880 dasd control for 3380 disk
(ten records/track) ... claiming 90% "hit rate". Issue was that there
was a lot of sequential file reading ... the 1st record read for track
would be a "miss" but bring in the whole track, resulting in the next
nine reads being "hits".

system services offered option for application doing sequential i/o to
specify full-track i/o (into processor memory) ... which would result
in the zero hit rate for the controller cache (IBM standard batch
operating system did contiguous allocation on file creation).

About the same time, we did system mod. that did highly efficient
trace/capture of every record operation which was deployed on numerous
production systems. Then traces were fed to sophisticated simulator that
could vary algorithms, caches, kinds of caches, sizes of caches,
distribution of caches, etc.

Given a fixed amount of cache storage, it was always better to have a
global system cache ... than partitioned/distributed; except a few edge
cases.  Example, if device track cache could be used to immediately
start transfering data, rather having to rotate to start of track before
starting transfer.

--
virtualization experience starting Jan1968, online at home since Mar1970