我什么时候应该使用GCC的-pipe选项?

Rob*_*edy 56 gcc pipe compiler-options

GCC 4.1.2的文件有这样说的-pipe选项:

-管

使用管道而不是临时文件进行编译的各个阶段之间的通信.这无法在汇编程序无法从管道读取的某些系统上运行; 但GNU汇编程序没有问题.

我假设我能够从错误消息中判断我的系统的汇编程序是否不支持管道,所以除了这个问题,我何时使用该选项才有意义?决定使用它应该考虑哪些因素?

Jos*_*ley 37

根据我们对中型项目的经验,添加-pipe在构建时间方面没有明显区别.我们遇到了一些问题(如果遇到错误,有时无法删除中间文件,IIRC),所以因为它没有获得任何东西,我们放弃使用它而不是试图解决这些问题.

  • 基于证据的答案+1,而不是"它不使用磁盘,所以它可能更好......" (15认同)
  • 请参阅@peterkarasev,了解-pipe在分布式文件系统中工作时确实会产生积极影响. (3认同)

Dig*_*oss 36

它通常没有任何区别

它有+-考虑因素.从历史上看,同时运行编译器和汇编器会给RAM资源带来压力.

根据今天的标准,Gcc很小,并且-pipe增加了一些多核可访问的并行执行.

但出于同样的原因,CPU速度非常快,以至于它可以创建该临时文件并在没有您注意的情况下将其读回.而且由于-pipe从来不是默认模式,它偶尔会起作用.单个开发人员通常会报告没有注意到时差.

现在,有一些大型项目.你可以查看一个构建所有Firefox或NetBSD的树,或者类似的东西.包含所有X的东西,比方说,作为次要的子系统组件.当作业涉及数千和数千个C文件中的数百万行代码时,您可能会或可能不会注意到差异.我相信你知道,人们通常只会同时处理这类事情的一小部分.但是,如果您是发布工程师或在构建服务器上工作,或者在stdio.h中更改某些内容,您可能希望构建整个系统以查看是否有任何损坏.而现在,每一次性能下降都可能......

  • `CPU是如此之快,以至于它可以创建该临时文件并将其读回,而您甚至没有注意到该语句是错误的.这里的瓶颈不是CPU,而是驱动器的I/O. 想象一下,由于某种原因,你正在编译一个慢速USB记忆棒的大项目:你会厌倦等待所有的读/写操作.当然GNU/Linux缓存文件而不是实际写入.但这不是海湾合作委员会的优点.那么**我们必须使用-pipe吗?**是的,最好使用它. (29认同)
  • @angel:我怀疑这样的i/o延迟甚至不会出现在现代系统的关键循环中:添加内存缓存的效果,只要你有足够的内存用于最近的文件,所有的实时操作都会发生在那里,随后发生在设备上的"真实写入",异步. (3认同)
  • @angel,因为OS具有可用的大RAM页面高速缓存,尤其是在RAM上安装了/ tmp(应如此)或没有完全恢复写屏障时,因此在这种情况下,I / O的实际开销仍然是CPU。 (2认同)
  • 当使用大型 C++ 模板(如 OpenSCAD 中的 CGAL)时,我发现阻止使用管道,而是要求它在文件上使用汇编器,可以防止机器耗尽 RAM 并触及交换空间。这是在 RAM 相对较低(如 512MB 或 1G)的机器上,也取决于是否使用了 -g 和 -O2 (2认同)

pet*_*sev 27

现在试试这个,当源/构建目的地在NFS(Linux网络)上时,构建起来要快得多.但内存使用率很高.如果您从未填充RAM并在NFS上拥有源代码,那么使用-pipe似乎是一场胜利.


Jef*_* Mc 10

老实说,没有理由不使用它.-pipe只会使用更多ram,如果这个框是构建代码,我认为它有一个不错的数量.如果您的系统使用更保守的文件系统来编写然后删除所有临时文件(例如,ext3),它可以显着缩短构建时间.

  • @JamesMoore当你遇到受约束的系统而不是处理目标平台上的内存问题时,你会进行交叉编译,对吗? (3认同)

小智 7

一个优点是使用 -pipe 将编译器与文件系统的交互更少。即使是 ram 磁盘,在使用临时文件时,数据仍然需要通过块 I/O 和文件系统层,而使用管道则变得更加直接。

对于文件,编译器首先需要完成写入,然后才能调用汇编器。管道的另一个优点是编译器和汇编器可以同时运行,并且它更多地使用了 SMP 架构。特别是当编译器需要等待来自源文件的数据(因为阻塞 I/O 调用)时,操作系统可以给汇编器完整的 CPU 时间,让它更快地完成工作。