【问题标题】:Should I optimize for size (-Os) for an I/O application我应该优化 I/O 应用程序的大小 (-Os)
【发布时间】:2015-07-04 11:01:00
【问题描述】:

我有一个受大量网络 I/O 限制的 C 应用程序。它目前在 gcc 上使用-O2 编译。使用-Os 显示构建应用程序可以减少 20% 的大小。一些基本测试显示性能没有可测量的下降(或增加)。

这是使用-Os 构建的好案例吗?有理由不这样做吗?我从来没有真正见过一个程序,无论它在 I/O 上花费了多少时间,都已经针对大小进行了编译。

【问题讨论】:

  • 尺寸对你来说重要吗?
  • 通常,只有 1% 的代码占用了 99% 的 CPU 时间。理想情况下,你会编译 1% 的速度和其余的大小。问题是编译器无法解决这个问题。尝试配置文件引导优化。

标签: c performance gcc


【解决方案1】:

优化不应影响程序的运行。因此,任何类型的优化都不应该影响程序使用的网络 I\O,以及与此相关的任何其他事情。如果您的程序发送 10 KB,即使经过优化,它也会发送相同的内容。

优化可能会影响structs 在其他方面的对齐方式(如代码大小、内存使用情况等),但根本不会影响逻辑(如果编程正确)。

通常,由于二进制文件往往相对较小(1MB 的二进制文件非常大),因此优化速度而不是大小更为常见。但是,这取决于您。

【讨论】:

  • 程序的大小不是意味着更好地使用 icache 吗?
  • 这真的取决于程序的具体用法。但是,在我的笔记本电脑中,我总共有 256KB 的 L1 缓存、1MB 的 L2 缓存和 6MB 的 L3 缓存。您的程序不太可能远大于 6MB,即便如此,其中大部分可能大部分都未使用。相信您的编译器会进行优化。
  • 关于优化的更多信息请参考这个问题 - stackoverflow.com/questions/19470873/…
  • 我在想,指令缓存中的任何空间节省都意味着系统上运行的其他程序可以使用它。这可能有点矫枉过正,但这有意义吗?
  • 视使用情况而定。运行了多少程序?您的程序代码中有多少是实际常用的?您使用的是哪个操作系统和平台?通常只有一小部分程序是常用的。为数据化的答案提供更多详细信息
猜你喜欢
  • 2013-12-21
  • 1970-01-01
  • 2013-04-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-01-22
  • 2011-03-25
  • 1970-01-01
相关资源
最近更新 更多