相关疑难解决方法(0)

所以我的理解是每个进程都有自己的虚拟内存空间,范围从0x0到0xFF .... F.这些虚拟地址对应于物理内存(RAM)中的地址.为什么这种抽象级别有用？为什么不直接使用直接地址？

我理解为什么分页是有益的,但不是虚拟内存.

我有一个项目,我被要求开发一个应用程序来模拟不同的页面替换算法如何执行(具有不同的工作集大小和稳定期).我的结果:

• 垂直轴:页面错误
• 水平轴:工作集大小
• 深度轴:稳定期

我的结果合理吗？我期望LRU比FIFO更好.在这里,它们大致相同.

对于随机,稳定期和工作集大小似乎根本不影响性能？我预计类似的图表如FIFO和LRU只是性能最差？如果引用字符串是高度稳定的(小分支)并且具有较小的工作集大小,那么具有许多分支和大工作集大小的应用程序应该仍然具有较少的页面错误？

更多信息

我的Python代码 | 项目问题

• 参考字符串长度(RS):200,000
• 虚拟内存大小(P):1000
• 主存储器的大小(F):100
• 引用的时间页数(m):100
• 工作组尺寸(e):2 - 100
• 稳定性(t):0-1

工作集大小(e)和稳定周期(t)会影响参考字符串的生成方式.

|-----------|--------|------------------------------------|
0           p        p+e                                  P-1

因此,假设上面是大小为P的虚拟内存.要生成参考字符串,使用以下算法:

• 重复直到生成参考字符串
  • m在[p,p + e]中选择数字.m模拟或引用页面被引用的次数
  • 选择随机数,0 <= r <1
  • 如果r <t
    • 生成新的p
    • 别(++ p)%P

更新(回应@ MrGomez的回答)

但是,回想一下您如何播种输入数据:使用random.random,从而为您提供具有可控熵级别的统一数据分布.因此,所有值都可能同样发生,并且因为您在浮点空间中构造了这些值,所以重现非常不可能.

我正在使用random,但它也不是完全随机的,虽然使用工作集大小和数字页引用参数,但是通过某些地方生成引用？

我尝试增加numPageReferenced亲戚,numFrames希望它能更多地引用当前在内存中的页面,从而显示LRU相对于FIFO的性能优势,但这并没有给我一个明确的结果.仅供参考,我尝试使用以下参数的同一个应用程序(页面/框架比率仍然保持不变,我减少了数据的大小以使事情更快).

--numReferences 1000 --numPages 100 --numFrames 10 --numPageReferenced 20

结果是

仍然没有这么大的差异.我是否正确地说,如果我numPageReferenced相对增加numFrames,LRU应该有更好的性能,因为它更多地引用内存中的页面？或许我错误地理解了什么？

对于随机,我正在思考:

• 假设高稳定性和小工作集.这意味着引用的页面很可能在内存中.那么页面替换算法运行的需求是否较低？

嗯,也许我要考虑更多:)

更新:在较低的稳定性下不太明显的垃圾

在这里,我试图显示垃圾,因为工作集大小超过内存中的帧数(100).然而,通知捶打似乎不太明显,稳定性较低(高t),为什么会这样？解释是,当稳定性变低时,页面错误接近最大值,因此工作集大小是多少并不重要？

我正在尝试使用此YouTube视频教自己LRU算法.在下面的例子中(取自这里)为什么0被3代替.不应该用4代替3,因为4是最少使用的吗？