我在谈论用C中的LRU内存页面替换算法实现,而不是
Java或C.

根据OS课程notes：

OK, so how do we actually implement a LRU? Idea 1): mark everything we touch with a timestamp.
Whenever we need to evict a page, we select the oldest page (=least-recently used). It turns out that this
simple idea is not so good. Why? Because for every memory load, we would have to read contents of the
clock and perform a memory store! So it is clear that keeping timestamps would make the computer at
least twice as slow. I

内存加载和存储操作应该非常快.是否真的有必要摆脱这些微小的操作？

在更换内存的情况下,从磁盘加载页面的开销应该比内存操作更重要.为什么实际上会关心内存和加载？

如果说明的说法不正确,那么实施具有时间戳的LRU的真正问题是什么？

编辑：

随着我深入挖掘,我能想到的原因如下.当页面命中时,会发生这些内存存储和加载操作.在这种情况下,我们不会从磁盘加载页面,因此比较无效.

由于预计命中率非常高,因此更新与LRU相关的数据结构应该非常频繁.这就是为什么我们关心在udpate过程中重复的操作,例如内存加载和存储.

但是,我仍然没有说服内存加载和存储的开销有多大.应该有一些测量.有人能指点我吗？谢谢！

最佳答案 内存加载和存储操作可以非常快,但在大多数实际情况下,内存子系统比CPU的执行引擎更慢 – 有时慢得多.

内存访问时间的粗略数字：

> L1缓存命中：2-4个CPU周期
>二级缓存命中：10-20个CPU周期
> L3缓存命中：50个CPU周期
>主内存访问：100-200个CPU周期

因此,实时加载和存储需要花费时间.使用LRU,每次常规内存访问也会产生内存存储操作的成本.仅此一项就可以使CPU执行的内存访问次数翻倍.在大多数情况下,这将减慢程序执行速度.此外,在页面驱逐时,需要读取所有时间戳.这将是非常缓慢的.

此外,不断读取和存储时间戳意味着它们将占用L1或L2缓存中的空间.这些缓存中的空间有限,因此其他访问的缓存未命中率可能会更高,这将花费更多时间.

简而言之 – LRU相当昂贵.