3 ms·
They are different caches. The database engines you’re talking about do that for pages not found in RAM, which need to be read from disk. This article is abou
by Const-me 6y ago
They are different caches.
The database engines you’re talking about do that for pages not found in RAM, which need to be read from disk.
This article is about accessing data that’s already present in system memory. The caches they are talking about are on-chip ones, i.e. L1D and L2 caches inside CPU cores, and L3 cache shared across cores but still located on the same CPU die.
Some rare CPUs like in my old laptop with Core i3-6157U even have L4 on-chip cache made of DRAM.
- jandrewrogers 6y agoThese are not different caches. Database engines do this with system memory and CPU cache, in addition to the disk cache. If you are implementing user space I/O and execution scheduling, you are already most of the way there. In fact, some have much more advanced scheduling around the CPU cache hierarchy than what was discussed in the paper. Some database engines don’t just prefetch memory, they also dynamically reorder the execution schedule to minimize CPU cache churn and save some memory bandwidth. A good database can easily retire tens of millions of page operations per second these days, giving them a considerable look ahead window. The technique discussed in the paper has been used in many systems for a long time. This was a standard design idiom for graph databases for at least 15 years, due to their intrinsically poor locality. Most advanced database kernel engineering techniques and architectures are not in the academic literature. That’s just the nature of the domain, they do massive amounts of R&D but rarely publish.