If I use "-O2" flag, the performance improves, but the compilation time gets longer.
如果我使用“-O2”标志,性能会提高,但编译时间会变长。
How can I decide, whether to use it or not?
我该如何决定是否使用它?
Maybe O2 makes the most difference in some certain types of code (e.g. math calculations?), and I should use it only for those parts of the project?
也许O2在某些类型的代码(例如数学计算?)中有最大的不同,我应该只将它用于项目的那些部分?
EDIT: I want to emphasize the fact that setting -O2 for all components of my project changes the total compilation time from 10 minutes to 30 minutes.
编辑:我想强调的是,为项目的所有组件设置-O2会将总编译时间从10分钟更改为30分钟。
6 个解决方案
#1
I would recommend using -O2 most of the time, benefits include:
我建议大多数时候使用-O2,好处包括:
- Usually reduces size of generated code (unlike -O3).
- More warnings (some warnings require analysis that is only done during optimization)
- Often measurably improved performance (which may not matter).
通常会减少生成代码的大小(与-O3不同)。
更多警告(某些警告需要仅在优化期间进行分析)
通常可以显着改善性能(这可能无关紧要)。
If release-level code will have optimization enabled, it's best to have optimization enabled throughout the development/test cycle.
如果发布级代码将启用优化,则最好在整个开发/测试周期中启用优化。
Source-level debugging is more difficult with optimizations enabled, occasionally it is helpful to disable optimization when debugging a problem.
启用优化后,源级调试会更加困难,有时在调试问题时禁用优化会很有帮助。
#2
I'm in bioinformatics so my advice may be biased. That said, I always use the -O3 switch (for release and test builds, that is; not usually for debugging). True, it has certain disadvantages, namely increasing compile-time and often the size of the executable.
我在生物信息学方面,所以我的建议可能有偏见。也就是说,我总是使用-O3开关(用于发布和测试版本,即通常不用于调试)。确实,它有一些缺点,即增加编译时间和通常可执行文件的大小。
However, the first factor can be partially mitigated by a good build strategy and other tricks reducing the overall build time. Also, since most of the compilation is really I/O bound, the increase of compile time is often not that pronounced.
但是,第一个因素可以通过良好的构建策略和其他减少整体构建时间的技巧来部分缓解。此外,由于大多数编译实际上是I / O绑定的,因此编译时间的增加通常不那么明显。
The second disadvantage, the executable's size, often simply doesn't matter at all.
第二个缺点,即可执行文件的大小,通常根本不重要。
#3
Never.
Use -O3 -Wall -Werror -std=[whatever your code base should follow]
使用-O3 -Wall -Werror -std = [无论你的代码库应该遵循什么]
#4
Always, except when you're programming and just want to test something you just wrote.
总是,除非你编程并且只想测试你刚写的东西。
#5
We usually have our build environment set up so that we can build debug builds that use -O0 and release builds that use -O3 (the build enviroment preserves the objects and libraries of all configurations, so that one can switch easily between configurations). During development one mostly builds and runs the debug configuration for faster build speed (and more accurate debug information) and less frequently also builds and tests the release configuration.
我们通常会设置构建环境,以便我们可以构建使用-O0的调试版本并发布使用-O3的版本(构建环境会保留所有配置的对象和库,以便可以在配置之间轻松切换)。在开发期间,一个主要构建和运行调试配置以实现更快的构建速度(以及更准确的调试信息),并且不太经常地构建和测试发布配置。
#6
Is the increased compilation time really noticable? I use -O2 all the time as the default, anything less just leaves a lot of "friction" in your code. Also note that the optimization levels of -O1, -O2 tends to be the best tested, as they are most interesting. -O0 tends to be more buggy, and you can debug pretty well at -O2 in my experience. Provided you have some idea about what a compiler can do in terms of code reordering, inlining, etc.
增加的编译时间真的很明显吗?我一直使用-O2作为默认值,不再只是在你的代码中留下了很多“摩擦”。另请注意,-O1,-O2的优化级别往往是最好的测试,因为它们最有趣。 -O0往往更加错误,你可以根据我的经验调试-O2。如果你对编译器在代码重新排序,内联等方面可以做些什么有所了解。
-Werror -Wall is necessary.
-Werror -Wall是必要的。
#1
I would recommend using -O2 most of the time, benefits include:
我建议大多数时候使用-O2,好处包括:
- Usually reduces size of generated code (unlike -O3).
- More warnings (some warnings require analysis that is only done during optimization)
- Often measurably improved performance (which may not matter).
通常会减少生成代码的大小(与-O3不同)。
更多警告(某些警告需要仅在优化期间进行分析)
通常可以显着改善性能(这可能无关紧要)。
If release-level code will have optimization enabled, it's best to have optimization enabled throughout the development/test cycle.
如果发布级代码将启用优化,则最好在整个开发/测试周期中启用优化。
Source-level debugging is more difficult with optimizations enabled, occasionally it is helpful to disable optimization when debugging a problem.
启用优化后,源级调试会更加困难,有时在调试问题时禁用优化会很有帮助。
#2
I'm in bioinformatics so my advice may be biased. That said, I always use the -O3 switch (for release and test builds, that is; not usually for debugging). True, it has certain disadvantages, namely increasing compile-time and often the size of the executable.
我在生物信息学方面,所以我的建议可能有偏见。也就是说,我总是使用-O3开关(用于发布和测试版本,即通常不用于调试)。确实,它有一些缺点,即增加编译时间和通常可执行文件的大小。
However, the first factor can be partially mitigated by a good build strategy and other tricks reducing the overall build time. Also, since most of the compilation is really I/O bound, the increase of compile time is often not that pronounced.
但是,第一个因素可以通过良好的构建策略和其他减少整体构建时间的技巧来部分缓解。此外,由于大多数编译实际上是I / O绑定的,因此编译时间的增加通常不那么明显。
The second disadvantage, the executable's size, often simply doesn't matter at all.
第二个缺点,即可执行文件的大小,通常根本不重要。
#3
Never.
Use -O3 -Wall -Werror -std=[whatever your code base should follow]
使用-O3 -Wall -Werror -std = [无论你的代码库应该遵循什么]
#4
Always, except when you're programming and just want to test something you just wrote.
总是,除非你编程并且只想测试你刚写的东西。
#5
We usually have our build environment set up so that we can build debug builds that use -O0 and release builds that use -O3 (the build enviroment preserves the objects and libraries of all configurations, so that one can switch easily between configurations). During development one mostly builds and runs the debug configuration for faster build speed (and more accurate debug information) and less frequently also builds and tests the release configuration.
我们通常会设置构建环境,以便我们可以构建使用-O0的调试版本并发布使用-O3的版本(构建环境会保留所有配置的对象和库,以便可以在配置之间轻松切换)。在开发期间,一个主要构建和运行调试配置以实现更快的构建速度(以及更准确的调试信息),并且不太经常地构建和测试发布配置。
#6
Is the increased compilation time really noticable? I use -O2 all the time as the default, anything less just leaves a lot of "friction" in your code. Also note that the optimization levels of -O1, -O2 tends to be the best tested, as they are most interesting. -O0 tends to be more buggy, and you can debug pretty well at -O2 in my experience. Provided you have some idea about what a compiler can do in terms of code reordering, inlining, etc.
增加的编译时间真的很明显吗?我一直使用-O2作为默认值,不再只是在你的代码中留下了很多“摩擦”。另请注意,-O1,-O2的优化级别往往是最好的测试,因为它们最有趣。 -O0往往更加错误,你可以根据我的经验调试-O2。如果你对编译器在代码重新排序,内联等方面可以做些什么有所了解。
-Werror -Wall is necessary.
-Werror -Wall是必要的。