Architectural Simulators Considered Harmful

Simulators Considered Harmful"/>

Architectural Simulators Considered Harmful

Architectural Simulators Considered Harmful（2015）

1. 摘要：
   • 模拟器工具发展的越来越复杂，虽然有益处，但是新一代的模拟器都是被容易滥用的抽象模型构建的，其中的某些一阶模型效果非常的差
   • 模拟器在使用时，通常作为一个黑盒，内部的错误都会被忽略，并且用户会依赖于无关设计点的验证
2. 一阶模型（first-order models）：包括非常广泛的技术，例如基于trace的模拟器，分析模型，数学证明或者是事件驱动的模拟器等
3. 体系结构模拟器的陷阱
   • 一阶现象模型很差的模拟器。某些新的模拟器，虽然非常有前途，但是在许多关键特征上存在问题或者是过于简化了模型
     • 模型中某些部分被过于简化。一种隐式的看法：未建模的部分影响都可以忽略，尽管事实不是。作者希望模拟器的发布者能够进一步提供 模拟器中某些部分的抽象的原因，同时显式的之处这些抽象会使得哪些场景在模拟器中不适用
     • 模拟器中某些部分过于详细。在某些模拟器中会嵌入较为复杂的模型来提供更好的功能。但是扩展这些复杂的模型可能会带来更多的不相容并且未验证的问题。作者意见不能够过于相信这些带有更细节的模拟器，而是应该在某些情况下，使用尽可能简单的模型
   • 将模拟器作为黑盒。尽管模拟器中存在问题，但是没有关注这些问题，而是选择了忽略
     • 无法访问的模拟器错误（inaccessible simulator errors）。模拟器大多使用C/C++，很多特性会被隐式的假设所掩盖，并且这些模拟器没有详细的文档和结果报告。尽管有些问题不会很重要，但是某些bug将会真实的影响的实际测试结果。作者建议在使用模拟器之前，使用自己的一些数据来验证模拟器在某些方面的正确性
     • 实验趋势论证（the trend myth）。大多数认为尽管模拟过程中有一些细节问题，但是大致趋势将是对的。但是想要做到这种假设，需要保证这些细节问题和研究问题之间并不相关。作者建议不能将神话的趋势验证作为不验证和不检查模拟器的借口
     • 验证的错误可信度估计。一个常见的误解，如果参数被更改，但是模拟器的精度将不会有很大的变化。即验证一个设计点的正确性，则代表了整个模拟器所有参数配置情况下的正确性。作者建议模拟器作者能够提供设计方法的详细信息，并考虑提供一个说明来介绍在验证点之外的模拟器的使用会出现什么问题。
   • 不利的评价标准
     • 有用的分析工作却得不到重视。一些使用了其它的更简单模型的分析工作不能够得到论文评审人员的推荐和青睐。作者建议社区鼓励作者在适当的时候使用一阶模型进行研究和发表。
     • 时钟级模型的滥用和过度使用。某些研究使用简单的一阶模型就可以得到好的结果验证，但是却是用了更加复杂的时钟级模拟器，同时使得结果更加的复杂和难以理解。这个问题仍旧是论文评审工作的问题。
     • 对一阶分析的低估。模型评估的最重要作用是深入了解想法的潜在机制或者是技术的影响。尽管复杂的模拟器能够产生很多的数据，但是却没有更加深入的解释。作者认为不论什么工作，都已经至少使用一阶分析模型对技术进行分析。
     • 放大的论文评审人员的噪声。评审人员仍旧非常在意论文的评估部分。
4. gem5中的几个bugs
   • 不一致的回写机制（inconsistent writeback mechanism）。gem5在乱序的模型中，只有当writeback buffers空闲的情况下，才能够调度指令发射。默认的发射宽度并不能代表实际的发射宽度。如果writeback buffers已经满了，此时发射宽度将被强制设置为0
   • 低效和错误标识（mislabeled）的微操作。
     • x86的微操作在gem5中不是为了高效，而只是为了保证正确性和经济性。这种做法会增加额外的寄存器依赖。例如由于微操作本身的定义，需要读取本不必要的目的寄存器。
     • 某些微操作使用的资源也被错误的指示。例如浮点数移动和load都不需要使用FP单元，但是却被指示为使用FP单元。在最坏的情况下，这些会导致浮点代码中对整数因子的功率进行了错误的估计
   • 流水线和时钟功率的错误。主要是McPAT v1.1的问题
   • 不一致的流水线恢复机制。在gem5的乱序模型中，一个load可能会引发两次pipeline reflush。一次是由于cache miss，另一次则是由于没有可用的MSHR。但是实际上只需要发生一次。