我希望在我的一个OpenGL项目中大力转向模板,主要是为了娱乐和学习体验.我计划仔细观察可执行文件的大小,看看有多少臭名昭着的膨胀发生.目前,当我支持速度时,我的Release版本的大小约为580 KB,当我喜欢大小时,我的大小为440 KB.
是的,这是一个很小的项目,实际上即使我的可执行文件大小只有10倍,它仍然会达到5 MB左右,按照今天的标准来看似乎不大......或者是它？这让我想到了我的问题.速度是否与大小成正比,或者是否存在特定阈值的跳跃和平稳期,我应该保持低于阈值？(如果是这样,具体的阈值是多少？)
lea*_*der 15
在大多数现代处理器上,局部性比尺寸更重要.如果您可以将所有当前正在执行的代码和大部分数据保存在L1缓存中,那么您将看到很大的胜利.如果你四处跳跃,你可能会强制将代码或数据从缓存中删除,然后很快再次需要它.
根据我的经验,"面向数据的设计"有助于代码和数据的本地化.您可能对面向对象编程幻灯片的陷阱(pdf)(这里是镜像(pdf))感兴趣,它可以很好地展示如何以这样的方式处理事物,从而获得良好的数据和代码局部性.
(顺便提一下,整个缓存大小和位置的事情是"优化大小"在某些情况下可以胜过"优化速度"的原因之一.)
Rob*_*vey 10
速度取决于很多因素.这就是为什么有一个遵循良好架构原则的合理程序设计是好的.
但是,如果应用程序设计正确,则可执行文件的实际大小与其性能几乎没有关系.通过分析应用程序和修复慢速部分所获得的性能改进只会影响代码的一小部分(10%或更少).
在任何给定的时刻(除非程序令人尴尬地并行,或者代码的性能关键部分碰巧非常大),无论如何只有一小部分代码在处理器内执行.
L1缓存尤其如此.原则上,大型程序的执行速度比较小的程序要慢,但实际上,如果保持性能关键部分足够小,性能关键代码应保留在L1缓存中.
请记住,紧凑的高性能循环只需将自身加载到L1缓存中一次,这是第一次循环.
可执行的"膨胀"对性能的影响小于以下两个因素(相关但不相同)
程序运行以执行工作单元所需的代码量(例如渲染帧)将影响指令缓存命中率和页表命中率.但是,如果90%的工作是在一个完全适合i-cache的小函数中完成的,那么整个程序的代码大小只会占到其他10%.
与数据类似,如果您的程序每帧必须触摸100MB数据,这将比具有适合L1,L2或L3缓存的工作集的程序执行得更糟.
所以它不是真正的可执行文件有多大,而是在任何时候都使用了多少"东西".