gcc -g调试标志会影响程序执行吗？

Question

我刚刚在测试我正在开发的程序，我发现当我使用-g编译它时，它执行速度会更快（这是一个具有统计学意义的变化），只快了3μs。这对我来说没有任何意义 - 我认为-g标志不应该影响程序执行，即使它这样做也会使其运行更慢而不是更快。

有人能告诉我为什么会这样吗？是否会改变程序的执行流程？我没有使用-O进行编译，因为我需要它按照原样执行，但如果-g可以在不改变指令顺序的情况下使其运行更快，那我显然应该使用-g。

所以我需要确切地知道-g标志对程序所做的更改。

编辑：我运行的测试越多，t值就越大（差异变得越来越有统计学意义）。这绝对不是测量误差 - 一定出了什么问题。

- Benubird

---

3微秒的变化真的具有统计学意义吗？这已接近系统时钟准确性的范畴，我会感到惊讶如果这不是随机噪声。 - templatetypedef

你所说的3us是指3微秒，即3μs = 3 * 10^-6 s吗？我认为这样小的误差可以归因于测量误差。 - R. Martinho Fernandes

@Martinho，系统性测量误差是无关紧要的，因为我正在比较差异，并且值通常分布。我使用Satterthwaite逼近的Welch's t检验，它允许基于随机误差的不确定性。您会推荐其他测试吗？ - Benubird

我没有使用 -O 进行编译，因为我需要按照编写的方式完全执行它。你能解释一下吗？为什么要放弃潜在的巨大性能提升，禁用优化，然后担心 3 微秒的差异？？？ - Paul R

可能是重复问题 使用-g标志进行优化时的性能损失 - gda2004

Answer 1

正如其他人所说，调试符号不会改变您的代码控制流，除非编译器出现了（不太可能的）错误。

但是它确实会改变执行，因为可执行文件变得更大，并且执行的代码在更多的页面上广泛分布。您可以期望有更多的缓存未命中和IO信号。在多任务环境中（即使是 Linux/busybox 系统也是如此），这可能导致稍微不同的调度行为。

另一方面，测量像您描述的这样微小的时间差异是一种艺术。您可能处于海森堡设置中，您的测量会影响执行时间。您的测量可能显示出统计学显着差异，但我在解释它们是否表示某个选项可以使代码更快时要非常谨慎。

- Jens Gustedt

---

这很有道理。但是，缓存未命中会使执行变慢，而不是更快吗？ - Benubird

@Benubird: 首先扰动测量。 - Jens Gustedt

@Benubird，我并没有说你的应用程序本身*更快。我是说应用程序加上你的测量组合起来可能会显得更快。 - Jens Gustedt

@Jens 仍然不明白这是怎么发生的。测量是程序的一部分，我没有使用外部的东西（比如时间），测量是通过 clock_gettime 在内部完成的。缓存未命中如何使其看起来更快？ - Benubird

我本打算回复一个“orly?”，因为调试部分没有被加载，而已经加载的部分内部布局不考虑调试部分，并且在可执行文件中排列以便于1:1映射加载。但是，调试部分似乎会防止未使用的符号被丢弃，因为调试器可能会引用它们，这会影响节内布局和加载的节大小。 - codeshot

Answer 2

-g 标志对实际生成的代码没有任何更改。它所做的是向可执行文件添加调试部分。这些部分在运行时不会加载，但调试器可以加载它们。由于可执行文件现在有点不同，它会变得更大 - 您可以尝试测量一个版本与另一个版本之间发生的页面错误数量，可执行文件在磁盘上存储的方式会发生变化，但没有代码更改。

如果您想查看汇编，请在二进制文件上运行 objdump -d 并进行比较

我确实质疑 3us 增加的有效性，可靠地测量 3us，至少在通用操作系统上是一项艰巨的任务 - 我希望您已经运行了您的程序数千次（可能是几十万次），以得出该数字并尝试消除影响此类测量的所有随机因素。

- nos

---

我实际上并没有在通用操作系统上运行它 - 它在一个专用的busybox系统上运行，只运行ptpd、cron、ssh和这个程序。时间非常准确，但由于执行需要大约1分钟的时间，所以不幸的是我没有时间运行成千上万次。 - Benubird

Answer 3

当我在其中一个子程序上使用-debug和-g标志时，我的代码得到了不同的答案，所以虽然我不知道为什么，但它肯定影响了程序的执行。

- Lisa

---

这并没有提供问题的答案。如果您想对作者进行批评或请求澄清，请在他们的帖子下留言。 - osyan

如果你的Karma值低于某个阈值（我相信是100），那么你将无法发表评论。 - Michael