sta*_*icx 1 optimization gcc compilation performance-testing compiler-optimization
我专注于GCC编译程序的CPU /内存消耗.
执行使用O3编译的代码在资源方面总是如此贪婪吗？
是否有任何科学参考或规范显示不同级别的Mem/cpu消耗的差异？
处理这个问题的人通常关注这些优化对执行时间,编译代码大小和能量的影响.但是,我找不到太多关于资源消耗的工作(通过启用优化).
提前致谢.
Bas*_*tch 12
不,没有绝对的方法,因为编译器中的优化是一门艺术(甚至没有很好地定义,并且可能是不可判定的或难以处理的).
但有些指导原则是:
在优化任何内容之前,请确保您的程序正确且没有错误,因此请调试并测试您的程序
有精心设计的测试用例和代表性基准(见本文).
确保你的程序没有未定义的行为(这很棘手,请看这个),因为如果你的代码中有UB ,GCC会奇怪地进行优化(但通常是正确的,根据C99或C11标准); 使用-fsanitize=样式选项(和gdb和Valgrind的调试阶段中....).
描述您的代码(在各种基准测试中),特别是找出哪些部分值得优化工作; 通常(但并不总是)大部分CPU时间都发生在一小部分代码中(经验法则:在20%的代码中花费80%的时间;在某些应用程序上,比如gcc编译器,这不是真的,请检查gcc -ftime-report询问gcc显示在各种编译器模块中花费的时间)....大多数时候 " 过早优化是所有邪恶的根源 "(但这种格言有例外).
提高你的源代码(如使用正确加以 restrict及const,添加一些编译指示或函数或变量属性,或者用一些明智GCC 建宏 __builtin_expect,__builtin_prefetch-请参阅本 - ,__builtin_unreachable...)
使用最近的编译器.海湾合作委员会目前的版本(2015年10月)是5.2(和2018年6月的海湾合作委员会8),并且在优化方面取得了持续进展; 您可以考虑从其源代码编译GCC以获得最新版本.
gcc -Wall -Wextra在编译器中启用所有警告(),并尽力避免所有这些警告 ; 只有当您要求优化时才会出现一些警告(例如-O2)
通常,编译-O2 -march=native(或者-mtune=native,假设你不是交叉编译,如果你确实添加了好的-march选项......)并用你的程序对你的程序进行基准测试
考虑链接时优化的编译和链接与-flto和相同优化标志.例如,放入CC= gcc -flto -O2 -march=native你的Makefile(然后-O2 -mtune=native从CFLAGS那里删除)......
-O3 -march=native通常也尝试(但并非总是如此,有时候你的代码可能会稍快-O2一些,-O3但这种情况并不常见)你可能会得到一点改进-O2
如果你想优化生成程序的大小,使用-Os的替代-O2或-O3; 更一般地,不要忘记阅读文档的控制优化选项部分.我想这两者-O2并-Os会优化堆栈使用(这是非常相关的内存消耗).并且一些GCC优化能够避免malloc(这与堆内存消耗有关).
你可能会考虑档案导引优化,-fprofile-generate,-fprofile-use,-fauto-profile 选项
潜入的文档GCC,它拥有众多的优化和代码生成参数(例如-ffast-math,-Ofast...)和参数 ,你可以花几个月的时间努力一些更多的人; 请注意,其中一些不是严格的C标准符合!
最近的GCC和Clang可以发出DWARF调试信息(如果已经应用了强大的优化,则以某种方式"近似"),即使在优化时也是如此,因此通过这两者-O2并且-g可能是值得的(您仍然能够在一些痛苦的情况下使用gdb优化的可执行文件上的调试器)
如果您有很多时间花费(数周或数月),您可以使用MELT(或其他一些插件)自定义GCC,以添加您自己的新(特定于应用程序)优化过程; 但这很困难(你需要了解GCC的内部表示和组织)并且可能很少值得,除非在非常具体的情况下(那些你可以证明花费数月时间来改进优化的理由)
您可能想了解程序的堆栈使用情况,因此请使用-fstack-usage
您可能想要了解发出的汇编代码,使用-S -fverbose-asm优化标志(并查看生成的.s汇编程序文件)
您可能想了解GCC的内部工作,使用各种-fdump-*标志(您将获得数百个转储文件!).
当然,上述待办事项列表应该以迭代和敏捷的方式使用.
对于内存泄漏错误,请考虑valgrind和几个-fsanitize= 调试选项.另请阅读垃圾收集(以及GC手册),特别是Boehm的保守垃圾收集器,以及关于编译时垃圾收集技术.
阅读GCC中的MILEPOST项目.
还要考虑OpenMP,OpenCL,MPI,多线程等......请注意,并行化是一项困难的艺术.
请注意,即使是GCC开发人员也经常无法预测此类优化的影响(对生成的二进制文件的CPU时间).不知何故,优化是一种黑色艺术.
或许gcc-help@gcc.gnu.org可能是一个讨论关于GCC优化的更具体,更准确和更有针对性的问题的好地方
你也可以在我接触basile的starynkevitch点net有更集中的问题......(并注明你原来的问题的URL)
对于有关优化的科学论文,你会发现很多.从ACM TOPLAS,ACM TACO等开始......搜索迭代编译器优化等......并更好地定义您想要优化的资源(内存消耗意味着什么都没有......).