我正在使用一些模板化程度很高的c ++代码。我可以使用AMD工具编译和配置文件,并在调试模式下困。但是,如果没有优化,大部分时间都集中在模板化代码和STL中。通过优化编译,我知道的所有配置文件工具都会生成垃圾信息。有没有人知道配置优化本机代码的好方法
PS1: 我写的代码也很模糊。在未经优化的代码中花费的大部分时间都将被优化掉。我说的是96-97%的运行时间花费在没有优化的模板化代码上。这将破坏分析的准确性。是的,我可以更改许多模板化代码,或者至少模板化代码的哪一部分引入了最大的麻烦,我可以在这些地方做得更好。
答案 0 :(得分:3)
您应该专注于您编写的代码,因为这是您可以更改的内容,在STL中花费的时间是无关紧要的,只需忽略它并专注于该代码的调用者。如果在STL中花费了太多时间,您可能可以调用其他STL原语而不是当前的原语。
分析未经优化的代码不太有趣,但您仍然可以获得一些信息。如果使用来自某些代码部分的算法是完全有缺陷的,它甚至会出现在那里。但是你应该能够从优化代码中的任何好的分析工具中获得有用的信息。您准确使用了哪些工具?为什么要将其输出称为垃圾?
通常也很容易手动检测您的代码,并确切地找出哪些部分是有效的,哪些不是。只需在精心选择的点调用定时器功能(或尽可能读取处理器的循环次数)即可。我通常从单元测试中做到这一点,以获得可重现的结果,但这一切都取决于你的程序的具体细节。
工具或仪器代码是优化的简单部分。困难的部分是找到在需要的地方获得更快代码的方法。
答案 1 :(得分:2)
“垃圾信息”是什么意思?
分析仅对优化构建有意义,因此工具可以与它们一起使用 - 因此,如果您获得无意义的结果,可能是由于分析器找不到正确的符号,或者需要检测构建。
例如,在英特尔VTune的情况下,我发现我从采样器得到了不可能的结果,除非我明确告诉它在哪里找到我正在调整的可执行文件的PDB。在仪器化版本中,我不得不调整设置,直到它可靠地将探针放入函数调用中。
答案 2 :(得分:1)
当@kriss说
时您应该专注于您编写的代码 因为这是你可以改变的
这正是我要说的。
我想补充一点,在我看来,更容易在没有优化的情况下对编译的代码进行性能调优,然后出于同样的原因打开优化器。如果你能解决的问题是花费多余的时间,那么无论编译器做什么都会花费相应的时间,并且在没有被加扰的代码中找到它会更容易。
我不会通过测量时间来寻找这样的代码。如果多余的时间是20%,那么我所做的就是随机暂停几次。一旦我看到2个或更多样品上可以明显改善的东西,我就找到了它。 It's an oddball method, but it doesn't really miss anything.我会测量前后的总时间,看看我节省了多少。这可以多次完成,直到找不到任何要修复的内容。 (顺便说一句,如果你在Linux上,Zoom是一种更自动化的方法。)
然后你可以打开优化器并查看它给你带来了多少,但是当你看到你所做的改变时,你会发现编译器真的没办法为你完成它。