编译器性能提升

㈠ 如何加快linux android 的编译速度

项目越来越大，每次需要重新编译整个项目都是一件很浪费时间的事情。Research了一下，找到以下可以帮助提高速度的方法，总结一下。
1. 使用tmpfs来代替部分IO读写
2.ccache，可以将ccache的缓存文件设置在tmpfs上，但是这样的话，每次开机后，ccache的缓存文件会丢失
3.distcc,多机器编译
4.将屏幕输出打印到内存文件或者/dev/null中，避免终端设备（慢速设备）拖慢速度。

tmpfs
有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟，也许这个数字是有点夸张了，不过粗想想，把文件放到内存上做编译应该是比在磁盘上快多了吧，尤其如果编译器需要生成很多临时文件的话。
这个做法的实现成本最低，在Linux中，直接mount一个tmpfs就可以了。而且对所编译的工程没有任何要求，也不用改动编译环境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel来测试一下编译速度：
用物理磁盘：40分16秒
用tmpfs：39分56秒
呃……没什么变化。看来编译慢很大程度上瓶颈并不在IO上面。但对于一个实际项目来说，编译过程中可能还会有打包等IO密集的操作，所以只要可能，用tmpfs是有益无害的。当然对于大项目来说，你需要有足够的内存才能负担得起这个tmpfs的开销。
make -j
既然IO不是瓶颈，那CPU就应该是一个影响编译速度的重要因素了。
用make -j带一个参数，可以把项目在进行并行编译，比如在一台双核的机器上，完全可以用make -j4，让make最多允许4个编译命令同时执行，这样可以更有效的利用CPU资源。
还是用Kernel来测试：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看来，在多核CPU上，适当的进行并行编译还是可以明显提高编译速度的。但并行的任务不宜太多，一般是以CPU的核心数目的两倍为宜。
不过这个方案不是完全没有cost的，如果项目的Makefile不规范，没有正确的设置好依赖关系，并行编译的结果就是编译不能正常进行。如果依赖关系设置过于保守，则可能本身编译的可并行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一个编译器驱动器。第一趟编译时ccache缓存了GCC的“-E”输出、编译选项以及.o文件到$HOME/.ccache。第二次编译时尽量利用缓存，必要时更新缓存。所以即使"make clean; make"也能从中获得好处。ccache是经过仔细编写的，确保了与直接使用GCC获得完全相同的输出。

ccache用于把编译的中间结果进行缓存，以便在再次编译的时候可以节省时间。这对于玩Kernel来说实在是再好不过了，因为经常需要修改一些Kernel的代码，然后再重新编译，而这两次编译大部分东西可能都没有发生变化。对于平时开发项目来说，也是一样。为什么不是直接用make所支持的增量编译呢？还是因为现实中，因为Makefile的不规范，很可能这种“聪明”的方案根本不能正常工作，只有每次make clean再make才行。
安装完ccache后，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，链到/usr/bin/ccache上。总之确认系统在调用gcc等命令时会调用到ccache就可以了（通常情况下/usr/local /bin会在PATH中排在/usr/bin前面）。
安装的另外一种方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路径加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
这样每次启动g++的时候都会启动/usr/lib/ccache/bin/g++，而不会启动/usr/bin/g++
效果跟使用命令行ccache g++效果一样
这样每次用户登录时，使用g++编译器时会自动启动ccache
继续测试：
用ccache的第一次编译(make -j4)：23分38秒
用ccache的第二次编译(make -j4)：8分48秒
用ccache的第三次编译(修改若干配置，make -j4)：23分48秒

看来修改配置（我改了CPU类型...）对ccache的影响是很大的，因为基本头文件发生变化后，就导致所有缓存数据都无效了，必须重头来做。但如果只是修改一些.c文件的代码，ccache的效果还是相当明显的。而且使用ccache对项目没有特别的依赖，布署成本很低，这在日常工作中很实用。
可以用ccache -s来查看cache的使用和命中情况：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，显然只有第二编次译时cache命中了，cache miss是第一次和第三次编译带来的。两次cache占用了81.7M的磁盘，还是完全可以接受的。
distcc
一台机器的能力有限，可以联合多台电脑一起来编译。这在公司的日常开发中也是可行的，因为可能每个开发人员都有自己的开发编译环境，它们的编译器版本一般是一致的，公司的网络也通常具有较好的性能。这时就是distcc大显身手的时候了。
使用distcc，并不像想象中那样要求每台电脑都具有完全一致的环境，它只要求源代码可以用make -j并行编译，并且参与分布式编译的电脑系统中具有相同的编译器。因为它的原理只是把预处理好的源文件分发到多台计算机上，预处理、编译后的目标文件的链接和其它除编译以外的工作仍然是在发起编译的主控电脑上完成，所以只要求发起编译的那台机器具备一套完整的编译环境就可以了。
distcc安装后，可以启动一下它的服务：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默认的3632端口允许来自同一个网络的distcc连接。
然后设置一下DISTCC_HOSTS环境变量，设置可以参与编译的机器列表。通常localhost也参与编译，但如果可以参与编译的机器很多，则可以把localhost从这个列表中去掉，这样本机就完全只是进行预处理、分发和链接了，编译都在别的机器上完成。因为机器很多时，localhost的处理负担很重，所以它就不再“兼职”编译了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然后与ccache类似把g++，gcc等常用的命令链接到/usr/bin/distcc上就可以了。
在make的时候，也必须用-j参数，一般是参数可以用所有参用编译的计算机CPU内核总数的两倍做为并行的任务数。
同样测试一下：
一台双核计算机，make -j4：23分16秒
两台双核计算机，make -j4：16分40秒
两台双核计算机，make -j8：15分49秒
跟最开始用一台双核时的23分钟相比，还是快了不少的。如果有更多的计算机加入，也可以得到更好的效果。
在编译过程中可以用distccmon-text来查看编译任务的分配情况。distcc也可以与ccache同时使用，通过设置一个环境变量就可以做到，非常方便。
总结一下：
tmpfs： 解决IO瓶颈，充分利用本机内存资源
make -j： 充分利用本机计算资源
distcc： 利用多台计算机资源
ccache： 减少重复编译相同代码的时间
这些工具的好处都在于布署的成本相对较低，综合利用这些工具，就可以轻轻松松的节省相当可观的时间。上面介绍的都是这些工具最基本的用法，更多的用法可以参考它们各自的man page。
5.还有提速方法是把屏幕输出重定向到内存文件或/dev/null,因对终端设备(慢速设备)的阻塞写操作也会拖慢速度。推荐内存文件，这样发生错误时，能够查看。

㈡ c++builder编译速度太慢，能不能通过设置来加快

C＋＋builder是最快的C＋＋编译器之一，从编译速度来说也可以说是最快的win32C＋＋编译器了。除了速度之外，C++builder的性能也在其它C＋＋编译器的之上，但许多delphi程序员仍受不了c++builder工程的编译速度。的确，delphi的速度要比任和c++的编译器都要快好多。Delphi在编译一个小工程的时候可能不到一秒，大的工程一般也在5秒钟这内编译完成了。

为什么delphi会比c++builder快这么多？是否有方法来c++builder的编译速度？本文就讲解了为什么C＋＋的编译器速度会慢，并且介绍了一个简单的方法来减少c++builder的编译时间。

为什么c++编译器的速度会慢？
c++builder 使用者怎么通过预编译头文件来减少编译时间？
讲解基于VCL可视化工程的预编译头文件方法
优化c++builder对预编译头文件的使用
结论
注意事项

为什么c++编译器速度慢？

在C＋＋中，你只能使用预定义或是预先声明了的函数，这意味什么？来看一个简单的例子，函数A()调用函数B（），函数A（）只能在函数B（）的原型或是函数体在A（）之前才能调用它

㈢ 应用编译优化有什么用

应用编译优化的作用是：提高运行能力因为程序优化前，有3个变量需要3个寄存器，一次乘法运算。程序优化后，只有1个变量需要一个寄存器，没有乘法运算。

并且这个优化看起来很微不足道，但实际上用途很广。为了程序的可读性和可维护性，大多数程序员应该还是会选用第一种方式。

写3行程序而不是直接甩下一行int ticks = 491520让后来读程序的人摸不到头脑。有了编译器的优化，程序员既可以写出易读的程序又不必担心性能受影响。

尤其是在嵌入式领域，很多低端芯片根本就没有硬件乘法器，如果程序不做上述优化可能这3行代码需要几十个cycle，优化过后一个cycle就搞定。

应用编译优化的级别：

第一级：代码调整。

代码调整是一种局部的思维方式；基本上不触及算法层级；它面向的是代码，而不是问题； 所以：语句调整，用汇编重写、指令调整、换一种语言实现、换一个编译器、循环展开、参数传递优化等都属于这一级。

第二级：新的视角。

新的视角强调的重点是针对问题的算法；即选择和构造适合于问题的算法。

第三级：表驱动状态机。

将问题抽象为另一种等价的数学模型或假想机器模型，比如构造出某种表驱动状态机；这一级其实是第二级的延伸，只是产生的效果更加明显，但它有其本身的特点。

㈣ 不同编译器的x265性能是否有差距

不同编译器的x265性能是有差距的：
MSVC系列的编译器都是渣优化，icc是针对跑分优化的，做不得数。目前来看gcc -O3的优化是最好的。
x265默认使用gcc编译就开了-O3选项。

㈤ 通过编译器对程序优化来改进cache性能的方法有哪几种

你的程序可能太短，看不出区别来，你比对一下她们生成的汇编码就知道了

CPU 缓存是为了提高程序运行的性能，CPU 在很多处理上内部架构做了很多调整，比如 CPU 高速缓存，大家都知道因为硬盘很慢，可以通过缓存把数据加载到内存里面，提高访问速度，而 CPU 处理也有这个机制，尽可能把处理器访问主内存时间开销放在 CPU 高速缓存上面，CPU 访问速度相比内存访问速度又要快好多倍，这就是目前大多数处理器都会去利用的机制，利用处理器的缓存以提高性能。

就算优化带来的效果非常有限，但是经过长年累月的持续优化，效果也是非常明显的，比如当年的Chrome浏览器就是靠打开网页非常快从而打败微软系统自带的IE浏览器。电脑手机等硬件的性能是有限的，不同的算法会产生不同的效率，今天我们就简单说一个选择问题，开发程序时是节省内存还是节省计算量。

㈥ 英伟达CPU问世：ARM架构，对比x86实现十倍性能提升

机器之心报道

机器之心编辑部

“只需一张 GeForce 显卡，每个学生都可以拥有一台超级计算机，这正是 Alex Krizhevsky、Ilya 和 Hinton 当年训练 AI 模型 AlexNet 的方式。通过搭载在超级计算机中的 GPU，我们现在能让科学家们在 youxian 的一生之中追逐无尽的科学事业，”英伟达创始人兼首席执行官黄仁勋说道。

4 月 12 日晚，英伟达 GTC 2021 大会在线上开始了。或许是因为长期远程办公不用出门，人们惊讶地看到在自家厨房讲 Keynote 的黄老板居然留了一头摇滚范的长发：

如果你只是对他的黑色皮衣印象深刻，先对比一下 2019、2020 和 2021 的 GTC，老黄气质越来越摇滚。如此气质，黄仁勋今天推出的新产品肯定将会与众不同。

“这是世界第一款为 terabyte 级别计算设计的 CPU，”在 GTC 大会上，黄仁勋祭出了英伟达的首款中央处理器 Grace，其面向超大型 AI 模型的和高性能计算。

英伟达也要做 CPU 了

Grace 使用相对能耗较低的 Arm 核心，但它又可以为训练超大 AI 模型的系统提供 10 倍左右的性能提升。英伟达表示，它是超过一万名工程人员历经几年的研发成果，旨在满足当前世界最先进应用程序的计算需求，其具备的计算性能和吞吐速率是以往任何架构所无法比拟的。

“结合 GPU 和 DPU，Grace 为我们提供了第三种基础计算能力，并具备重新定义数据中心架构，推进 AI 前进的能力，”黄仁勋说道。

Grace 的名字来自于计算机科学家、世界最早一批的程序员，也是最早的女性程序员之一的格蕾丝 · 赫柏（Grace Hopper）。她创造了现代第一个编译器 A-0 系统，以及第一个高级商用计算机程序语言“COBOL”。计算机术语“Debug”（调试）便是她在受到从电脑中驱除蛾子的启发而开始使用的，于是她也被冠以“Debug 之母”的称号。

英伟达的 Grace 芯片利用 Arm 架构的灵活性，是专为加速计算而设计的 CPU 和服务器架构，可用于训练具有超过 1 万亿参数的下一代深度学习预训练模型。在与英伟达的 GPU 结合使用时，整套系统可以提供相比当今基于 x86 CPU 的最新 NVIDIA DGX 快 10 倍的性能。

目前英伟达自家的 DGX，使用的是 AMD 7 纳米制程的 Rome 架构 CPU。

据介绍，Grace 采用了更为先进的 5nm 制程，在内部通信能力上，它使用了英伟达第四代 NVIDIA NVLink，在 CPU 和 GPU 之间提供高达 900 GB/s 的双向带宽，相比之前的产品提升了八倍。Grace 还是第一个通过错误校正代码（ECC）等机制利用 LPDDR5x 内存系统提供服务器级可靠性的 CPU，同时提供 2 倍的内存带宽和高达 10 倍的能源效率。在架构上，它使用下一代 Arm Neoverse 内核，以高能效的设计提供高性能。

基于这款 CPU 和仍未发布的下一代 GPU，瑞士国家超级计算中心、苏黎世联邦理工大学将构建一台名为“阿尔卑斯”的超级计算机，算力 20Exaflops（目前全球第一超算“富岳”的算力约为 0.537Exaflops），将实现两天训练一次 GPT-3 模型的能力，比目前基于英伟达 GPU 打造的 Selene 超级计算机快 7 倍。

美国能源部下属的洛斯阿拉莫斯国家实验室也将在 2023 年推出一台基于 Grace 的超级计算机。

GPU+CPU+DPU，三管齐下

“简单说来，目前市场上每年交付的 3000 万台数据中心服务器中，有 1/3 用于运行软件定义的数据中心堆栈，其负载的增长速度远远快于摩尔定律。除非我们找到加速的办法，否则用于运行应用的算力将会越来越少，”黄仁勋说道。“新时代的计算机需要新的芯片、新的系统架构、新的网络、新的软件和工具。”

除了造 CPU 的大新闻以外，英伟达还在一个半小时的 Keynote 里陆续发布了大量重要软硬件产品，覆盖了 AI、 汽车 、机器人、5G、实时图形、云端协作和数据中心等领域的最新进展。英伟达的技术，为我们描绘出了一幅令人神往的未来愿景。

黄仁勋表示，英伟达全新的数据中心路线图已包括 CPU、GPU 和 DPU 三类芯片，而 Grace 和 BlueField 是其中必不可少的关键组成部分。投身 Arm 架构的 CPU，并不意味着英伟达会放弃原有的 x86、Power 等架构，黄仁勋将英伟达重新定义为“三芯片”公司，覆盖 CPU、GPU 和 DPU。

对于未来的发展节奏，黄仁勋表示：“我们的发展将覆盖三个产品线——CPU、GPU 和 DPU，以每两年一次更新的节奏进行，第一年更新 x86，第二年就更新 Arm。”

最后是自动驾驶。“对于 汽车 而言，更高的算力意味着更加智能化，开发者们也能让产品更快迭代。TOPS 就是新的马力，”黄仁勋说道。

英伟达将于 2022 年投产的 NVIDIA 自动驾驶 汽车 计算系统级芯片——NVIDIA DRIVE Orin，旨在成为覆盖自动驾驶和智能车机的 汽车 中央电脑。搭载 Orin 的量产车现在还没法买到，但英伟达已经在为下一代，超过 L5 驾驶能力的计算系统作出计划了。

Atlan 是这家公司为 汽车 行业设计的下一代 SoC，其将采用 Grace 下一代 CPU 和下一代安培架构 GPU，同时也集成数据处理单元 (DPU)。如此一来，Atlan 可以达到每秒超过 1000 万亿次（TOPS）运算次数。如果一切顺利的话，2025 年新生产的车型将会搭载 Atlan 芯片。

与此同时，英伟达还展示了 Hyperion 8 自动驾驶 汽车 平台，业内算力最强的自动驾驶 汽车 模板——搭载了 3 套 Orin 中心计算机。

不知这些更强的芯片和系统，能否应付未来几年里人们对于算力无穷无尽的需求。在 GTC 2021 上，英伟达对于深度学习模型的指数增长图又更新了。“三年间，大规模预训练模型的参数量增加了 3000 倍。我们估计在 2023 年会出现 100 万亿参数的模型。”黄仁勋说道。

英伟达今天发布的一系列产品，让这家公司在几乎所有行业和领域都能为你提供最强大的机器学习算力。在黄仁勋的 Keynote 发表时，这家公司的股票一度突破了 600 美元大关。

“20 年前，这一切都只是科幻小说的情节；10 年前，它们只是梦想；今天，我们正在实现这些愿景。

英伟达每年在 GTC 大会上发布的新产品，已经成为了行业发展的风向。不知在 Grace 推出之后，未来我们的服务器和电脑是否会快速进入 Arm 时代。

㈦ 在不考虑编译器优化等因素下，下面那个运算比较快

下面是在编译器不优化的情况下的代码反汇编后的结果
14: if (a > b)//我们看到，只有3条指令，
0040104D mov edx,dword ptr [ebp-4] //将a放入寄存器EDX
00401050 cmp edx,dword ptr [ebp-8] //比较EDX和b的大小
00401053 jle main+3Ch (0040105c) //如果a<b跳转到0040105c
15: {
16: return 1;
00401055 mov eax,1
0040105A jmp main+4Fh (0040106f)
17: }
18: if (a - b > 0)//我们看到有4条指令
0040105C mov eax,dword ptr [ebp-4]//将a放入EAX
0040105F sub eax,dword ptr [ebp-8]//a-b的差放入EAX
00401062 test eax,eax//比较EAX是否为0
00401064 jle main+4Dh (0040106d)//条件跳转
19: {
20: return 2;
00401066 mov eax,2
0040106B jmp main+4Fh (0040106f)
21: }
所以我认为if (a > b) {....}
效率更高

㈧ 谁有c语言的好的编译器，要性能够多够好，中文版的，有的请发到邮箱[email protected]谢谢了！！

1. GCC
大名鼎鼎的GNU的C/C++/Obj-C编译器, 当前版本是2.8.1, 但据说与2.7.*有兼容性
问题. 而使用较广的是gcc 2.7.2系列, 如RedHat5中带的就是gcc 2.7.2.3
有时候在Cyrix上用gcc会有些问题, 因此有一套针对Cyrix特点的gcc 2.7.2.3
我这里有RedHat5的rpms ftp://166.111.68.98/pub/Warez-CD/Huricane-contrib
(Cyrix 2.7.2.3 & 2.8.1)

其基本结构就是一个front end和back end,
/usr/bin/gcc 就是个front end, 其kernel东西都放在 /usr/lib/gcc-lib下面,
cpp是C预处理器, cc1*的1M多的就是编译器的核心模块了
cc1 C compiler
cc1plus C++ compiler
cc1obj Object-C compiler
但gcc并没有集成Fortran的compiler, 一般要用f2c转成C后才用gcc编译
好象也还有个g77 Fortran compiler吧?

gcc的不断发展完善使许多commercial compiler都相形见绌, 那当然, gcc/emacs
都由GNU创始人Richard Stallman手创, 是GNU的旗舰产品, 质量当然没得说了:-)
由于 Unix平台的高度可移植性, gcc几乎在各种常见的Unix平台上都有, 即使是
Win32/DOS也有gcc的port. 比如说该死的Solaris普通版本连compiler都没有, 也
就只好用gcc了...

2. EGCS(Experimental/Enhanced GNU Compiler System)
这是gcc的发展方向, 把fortran等编译器集成进来, 也许还会有Pascal?
它的构造很清晰, 把对gcc的各种改进/port都集成回去. 如gcc 2.7系列据说是
没有对Pentium进行优化的, 而egcs则把pgcc对Pentium的一些优化集成进去了
现在gcc的开发工作主要就是egcs, 由Cygnus公司领导(?), 这Cygnus公司还是很
不错的, 还出了GNU-Win32, SourceNavigator等, 是GNU的坚实拥护者:-))

包括了C/C++/Obj-C/Fortran 编译器, 当前最新版本1.0.2, 还在不断开发中
昨天download发现KDE Beta4都用egcs编译了 :-)

Fortran集成进来后在/usr/lib/gcc-lib下又多了个f771的back end, 当然
还是g77/f77 编译
我这里有egcs 1.0.2 的rpm 在RH5-CD/collect下面

3. PGCC(Pentium GCC)

针对Pentium CPU进行了编译器优化的compiler
pgcc据说用JPEG压缩解压缩测试最快可比gcc快 30%!
新版的pgcc都是基于egcs的, 以一个patch的形式release