多核编译命令
A. 如何让gcc支持多核编译
四核四线程用 make -j5
四核八线程用 make -j9
经常搞大量重复编译，建议使用ccache
B. 有什么办法可以加速make的编译耗时，以利用到底层的多核硬件
在使用 makefile 工具对多个源程序进行编译、连接时，首先必须要确保你需要编译的程序都是正确的，然后将编译各个源程序按照一定的先后顺序写入到一个 makefile 文件中（缺省名称叫 makefile，但是也可以使用别的文件名），在此编译过程中，到底哪一个源程序是只编译、不连接；
哪一个源程序是需要等别的源程序都编译好了之后，再进行最后的连接，这些都必须写清楚。
C. vs2010编译QT4.8.6，designer.exe、assistant.exe无法运行
认真核对操作步骤：
1、修改环境变量工具推荐：Rapid Environment Editor。
修改前请先备份当前的环境变量。然后：
(1)检查系统变量path，删除有关mingw其他版本等信息，以免与后续的mingw32-make冲突。
(2)检查用户变量INCLUDE、LIB、PATH、MSDevDir和MSVCDir，删除有关\Microsoft Visual Studio\VC98的信息，因为它们会与后续的mingw32-make冲突，导致编译出错。
2、在电脑上安装mingw编译器，假设路径安装在C:\Qt\mingw32。将C:\Qt\mingw32\bin添加进环境变量path，打开DOS命令行输入gcc --version和g++ --version和mingw32-make --version验证编译器安装成功。我用的MinGW版本是V4.8.2，
3、解压qt-everywhere-opensource-src-4.8.6.zip并进入目录。例如：D:\qt-everywhere-opensource-src-4.8.6\
4、依次执行以下DOS命令：
(1)configure -debug-and-release -opensource -prefix "D:\Qt4.8.6" -platform win32-g++ -nomake demos -nomake examples
常见的使用选项说明：
-debug-and-release 编译debug和release版
-opensource 选择开源协议并确认
-platform win32-g++ 使用mingw编译
-prefix "D:\Qt4.8.6" 指定编译结果目录,如果未指定则默认当前
-shared 创建和使用共享Qt库
-static 创建和使用静态Qt库
-nomake demos -nomake examples 不编译例程
-nomake tests 不编译tests
-skip qtwebkit 忽略qtwebkit，因为编译它特别消耗时间
-mp 使用多核优化编译
(2)mingw32-make
(3)mingw32-make install
5、编译完成后，把C:\Qt\mingw32\bin\路径下的三个文件libgcc_s_dw2-1.dll、libstdc++-6.dll和libwinpthread-1.dll拷贝到D:\qt-everywhere-opensource-src-4.8.6\bin\。另外，也请把步骤1备份的环境变量还原。
6、修改Qt安装路径
最初编译时选择的路径是D:\Qt4.8.6\。如果想将它复制到其他盘符，并且改名，例如：C:\Qt\4.8.6_MinGW。这样一来会有问题吗？是的，会有问题，因为Qt有绝对路径依赖症。改名后C:\Qt\4.8.6_MinGW\bin\的exe执行程序都会出问题，要么程序打不开，要么多国语言发生异常。用记事本打开C:\Qt\4.8.6_MinGW\bin\qmake.exe，查找关键字“qt_prfxpath”，可以看到里面含有原始的安装路径。我们不可以手动去修改qmake.exe，真正有效的解决方法是：
在C:\Qt\4.8.6_MinGW\bin\路径下创建一个qt.conf文件，内容为
[paths]
Prefix = C:/Qt/4.8.6_MinGW
请注意：qt.conf文件必须是ANSI格式，并且Prefix的斜杠风格采取的是linux的，而非Windows，否则会失效。或者使用"Prefix = .. "，如此一来，任意路径有效。
D. 怎样ubuntu环境下编译内核详解
步骤/方法
一、下载源代码和编译软件的准备
下载内核源代码：http://www.kernel.org/
注意，点击2.6.25内核的F版，即完整版。
如果你懒得去网站点联接，运行下列命令：
代码:$cd ~$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.10.tar.bz2
安装有关编译程序。安装make ,gcc, make-kpkg,运行menuconfig等等和编译内核相关的工具。安装不了，请检查/etc/apt/sources.list 文件。有关命令：代码:$sudo apt-get install build-essential kernel-package libncurses5-dev
二、解压源代码注意，网上很多教程上说应该解压到 /usr/src,纯属以讹传讹，linux掌门人linus说解压到任何目录上都可以。当然，linus的说法是正确的。我放在自己的主目录下的src目录。如果你下载源代码是放到自己的主目录下或者运行上面的wget下载的，那么运行下列命令：代码:$ cd ~$ mkdir src && tar jfx linux-2.6.25.10.tar.bz2 -C src/现在，源代码就在 ~/src/linux-2.6.25.10进入源代码的目录，准备下一步的工作。后面都在这个目录里面进行。代码:$ cd ~/src/linux-2.6.25.10
三、开始编译前的准备工作。首先，清理以前编译时留下的临时文件。如果是刚刚解开的包，不需要执行这步。如果是第二次或者是第n次编译，那么一定要执行。相关命令如下：代码:$ sudo make mrproper网上很多教程上说把现在使用的内核的config拷贝过来参考，据实验，是不需要的，ubuntu还有debian会自动做这步。不过这条命令倒是可以学习一下。当然你可以将以前的配置拷贝过来。命令：代码:cp /boot/config-`uname -r` ./.config
四、开始配置内核选项。相关命令：代码:$sudo make menuconfig配置用到的键只有几个，esc退出菜单;空格改变选项状态;光标键上下左右移动,回车选定。选项意义：M是编译成可以随时加入的模块，*是编译进入内核，空就是不要。配置选项非常多，具体配置可以参考金步国先生翻译的资料：Linux 2.6.19.x 内核编译配置选项。参考网址：http://lamp.linux.gov.cn/Linux/kernel_options.html为了一次成功，请大家遵循一个原则，如果你自己使用的内核已经选用了某个选项，如果你没用充分的理由，不要随便改动。这样虽然内核不那么精简，但是不容易出现问题。我们可以精简的部分是硬件模块部分，对于自己没有的硬件要毫不犹豫的清除。如果你很执着，或者你有洁癖，你也可以一项项对过去，按照金步国先生的资料描述去选择基本上没有问题。
五、必须强调的几个选项:1、
在“General setup”里面的“Prompt for development and/or incomplete
code/drivers”金步国认为是不需要。但是如果你的硬件比较新，那几乎是必须选的，这样，我们才可以找到4965无线网卡，alsa声音驱动等
等。Kernel log buffer size 我选15，双核。如果你用ia64，要选16。Control Group support 集群支持？可以不要Choose SLAB allocator (SLUB (Unqueued Allocator)) 内存管理模式slab和slub选择slub。
2、在“Block layer”里，假如没有2TB的硬盘，就去掉：Support for Large Block Devices 。Support for Large Single Files 也不需要，谁有2TB的文件？
3、Processor type and features中是关于cpu的，要认真选。Symmetric multi-processing support是打开多核的开关，我的cpu是双核的，选中。Processor family (Core 2/newer Xeon) 我的是Core 2/newer Xeon。找到自己的cpu后，把Generic x86 support选项取消。Subarchitecture Type 选(PC-compatible)Maximum number of CPUs 输入自己的核心数目，我输入2。SMT (Hyperthreading) scheler support说的是超线程技术，P4有支持的，我的t8100不支持，目前大部分市场上的家用cpu都不支持。High Memory Support (4GB) 1G以下选1G；我是3G，选4G；4G以上的选16G在“ Timer frequency ”里，默认是250Hz，较新的cpu都可以选择了1000Hz，性能更好。
4、Power management options中把APM (Advanced Power Management) BIOS support关闭。现在的电脑都用acpi了。CPU Frequency scaling 是笔记本cpu节电技术Default CPUFreq governor (conservative) cpu节电模式有四个，笔记本默认选conservative比较好。ACPI Processor P-States driver 必须选，不然CPU Frequency就不能用。后面的可选自己硬件相关的，我选的是Intel Enhanced SpeedStep和 Intel Speedstep on ICH-M chipsets，其他的统统消灭。
5、Bus options的选择：Bus options (PCI, PCMCIA, EISA, MCA, ISA)PCI support PCI Express support 现在新买的机器基本上都是PCI Express了ISA support 较新的新机器没有ISA设备，可以去掉MCA support 去掉NatSemi SCx200 support 去掉PCI Hotplug Support Support for PCI Hotplug (EXPERIMENTAL) 如果没有PCI热插拔设备，去掉这里的选项可以考虑全部编译进内核，而不是以模块形式存在。
6、Device Drivers是重点，由于linux不但面向个人工作站，更多的是面向服务器的应用，所以可以把自己机器上没有的硬件全部去掉，而不用面面俱到。但是通用型的选项要慎重。比如在网卡的部分，除了我的千兆网卡 Broadcom Tigon3 support和4965无线网卡Intel Wireless WiFi 4965AGN，其余的硬件支持统统去掉。再比如声卡部分，我的是hd声卡，我只是在PCI devices中，选intel hd 声卡，再选Build IDT/Sigmatel HD-audio codec support，除此之外的硬件支持全部去掉。
声卡还有一个细节，在ubuntu7.10里面， 需要在/etc/modprobe.d/alsa-base后面添加options
snd-hda-intel probe_mask=1
model=3stack，这样我的笔记本喇叭才可以发声，不然只有外接耳机或者音箱。这次编译以后，这个动作就不必了，但是两个耳机插口只有一个可以用
了。再比如我的电脑中没有agp，就可以直接把agp相关的选项全部取消。要注意的：ATA/ATAPI/MFM/RLL support Include IDE/ATA-2 DISK support 如果你的/boot是放在IDE硬盘上，那么这里一定要选＊，选M都不行。否则启动时会出现“waiting for root file system”的提示而停滞不前。 SCSI emulation support 要用刻录机，必须选。SCSI device support 现在都是SATA硬盘，一定要选＊ SCSI disk support 如果你的/boot放在SATA硬盘上，一定要选＊。
SCSI CDROM support 虽然康宝刻录机是ide接口的，但是必须把它当成scsi接口的，这是老问题了。用刻录机，必须选。
Graphics supportSupport for frame buffer devices 选中，进入选择 VESA VGA graphics support 选上，不然字符界面启动会有问题，后面的显卡选择：由于我的显卡是nvidia 8400gs，要自己安装nvidia公司的驱动，所以一个都没有选。这样导致ubuntu开机动画会出问题，我索性在grub中的splash字符全部删除，把开机动画关闭。字符界面很正常。 Console display driver support 有人开机后字符控制台错误，就是这部分选项没有选，出问题了。 Framebuffer Console support 需要打开。
Bootup logo 开机图标，会在自检的画面上加上个性图标。需要在grub上添加“vga＝”的选项，可以参考http://dotimes.com/articles /t23-slackware-framebuffer.html7、File systemsFilesystem in Userspace support 简称fuse。是必选的，如果你要用windows分区。
CD-ROM/DVD Filesystems ISO 9660 CDROM file system support 一般选＊DOS/FAT/NT Filesystems VFAT (Windows-95) fs support 有FAT32分区就选＊吧 NTFS file system support 有NTFS分区就选＊吧 NTFS write support 如果想对 NTFS分区进行写操作，选＊必须将启动盘的文件系统编译进内核，默认是编译成模块，这样无法启动系统。ubuntu采用的文件系统是ext3,请把ext2,ext3相关的必要选项都编译进入内核。
8、Virtualization这个大类是我多花几百元买t8100的主要原因，因为t8100支持intel vt技术使linux上的虚拟机的性能大幅度提高。这里的选项我除了amd的，其他都编译成模块。
9、全部设置完成，最后一项是保存设置。按照我的习惯，先在上一层目录保存一个备份，文件名类似 ../config20080630然后再保存到当起目录,文件名 .config退出设置程序。
六、开始编译内核。ubuntu的工具是make-kpkg,和其他的发行版相比，步骤相对简单。相关命令:代码:$sudo make-kpkg clean 这条命令好像不要超级权限，很多资料上说要，不过这不是原则问题。
$ sudo make-kpkg -initrd --initrd --append-to-version=dell1400 kernel_image kernel-headers上述命令中的dell1400可以用自己喜欢的字符代替，最后的字符一定是数字.输完上述命令回车之前，建议大家把浏览器还有别的运用程序都关掉，机器开始的工作比较艰苦。
我的机器大概十几分钟。
七、安装内核编译完成就是安装工作。编译好的内核在上一层目录。包括linux-headers-...-_i386.deb和linux-image-...-i386.deb两个文件，如果你不搞开发的话，只要安装内核就可以，头文件以后要用的时候再说。安装相关命令：
代码:$ cd ..$ sudo dpkg -i linux-image-（按tab键）文件名很长，如果不用tab自动补足是不可能的，tab键万岁。安装完成后和老内核比较一下大小代码:
$ ls -l /boot/
八、重新启动验证新内核。代码:$ sudo reboot
九、显卡驱动如果你的显卡和我一样是nvidia显卡，启动之后往往无法正常进入x－window。即使能看到gdm登录界面，效果也是很差的。那么就要安装nvidia驱动。用ctrl+alt+f1 进入字符命令行，输入用户名，密码登录。命令：代码:下载驱动$ wget http://us.download.nvidia.com/XFree86/Linux-x86/173.14.12/NVIDIA-Linux-x86-173.14.12-pkg1.run$sudo －s输入密码取得超级权限。＃ps ax看看和gdm相关的进程，把这些进程全部关闭;用sudo /etc/init.d/gdm stop有可能有一个进程没有关闭：＃kill 进程号然后安装nvidia显卡驱动,当然驱动要先下好，到nvidia驱动所在的目录里，运行：＃ sh ./NVIDIA-Linux-x86-173.14.12-pkg1.run重新启动以后就ok。要用nvidia的驱动，每次升级内核都要这么做。
十、无线网卡相关的内核选项是Networking --->Wireless --->Generic IEEE 802.11 Networking Stack (mac80211)还有4965的驱动。4965
无线网卡驱动虽然已经编入内核，但没有firmware无法使用。需要把原来内核的firmware拷贝到新内核对应的目录，名字和内核一致,我的内核是
linux－image-2.6.25.10dell1400，那建的目录名就是2.6.25.10dell1400。代码:具体命令：$ cd /lib/firmware/$ sudo mkdir 2.6.25.10dell1400把你的老内核中的4965的firmware拷贝过来。$ sudo cp 2.6.24-16-generic/* 2.6.25.10dell1400/上面的命令和下面的命令是等价的：$ cd /lib/firmware/$ sudo cp -R 2.6.24-16-generic/ 2.6.25.10dell1400/
重新启动系统，无线网卡就正常了。
附编译使用的机器配置：dell vostro 1400,t8100,nvidia 8400cs显卡，内置SigmaTel STAC9228芯片的声卡，4965无线网卡，BCM5906M千兆网卡，3G内存,160G硬盘,combo刻录。
编译系统版本：ubuntu 8.04桌面版.
E. 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,因对终端设备(慢速设备)的阻塞写操作也会拖慢速度。推荐内存文件，这样发生错误时，能够查看。
F. android 怎样编译kernel 命令 make
方法如下：
在Linux的环境下:
建立目录:
mkdir ~/android-kernel cd android-kernel
下载源代码, 大概有280MB, 慢慢等哈~~~ (当然你要先安装git) git clone git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git
类似的屏幕信息:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/ remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016) Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done. Resolving deltas: 100% (755115/755115), done. Checking out files: 100% (22584/22584), done.
然后去到htc-msm branch: cd kernel
git checkout -b htc-msm origin/htc-msm
屏幕信息:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm. Switched to a new branch "htc-msm"
下载ARM的toolchain, 大概64MB左右, 下到~/android-kernel: 下
载
:
http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
编译kernel
准备缺省的Kaiser 配置文件.config
cd ~/android-kernel/kernel
make htckaiser_defconfig ARCH=arm
然后编译zImage:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
编译好的在: ~/android-kernel/kernel/arch/arm/boot/zImage
如果你的机器是多核的, 可以编译的时候用-j <cores/cpus_number>来加速:
比如, 双核的可以:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi
满意请采纳谢谢
G. intel fortran如何实现单机多核并行运算
请使用openmp。
打开OpenMP支持，方法如下：
选择项目(Project) -> 属性(property) -> Fortran -> 语言(Language),在 Process OpenMP Directives 选项中选择 Generate Parallel Code (/Qopenmp),点击确定以打开 OpenMP 支持。
示例代码：
H. QT5静态编译无法加载数据库插件
今天终于自己静态编译过了QT5.3.1, 成功用在项目上了, 记录下configure指令.
configure -confirm-license -opensource -platform win32-msvc2013 -mp -debug-and-release -static -prefix "E:\Qt\5.3.1-static-vs2013" -qt-sql-sqlite -qt-zlib -qt-libpng -qt-libjpeg -opengl desktop -qt-freetype -no-qml-debug -no-angle -nomake tests -nomake examples -skip qtwebkit
其中 -mp 是启用多核编译的开关
I. python如何利用多核处理器
GIL 与 Python 线程的纠葛
GIL 是什么东西？它对我们的 python 程序会产生什么样的影响？我们先来看一个问题。运行下面这段 python 程序，CPU 占用率是多少？
# 请勿在工作中模仿，危险:)def dead_loop(): while True: passdead_loop()
答案是什么呢，占用 100％ CPU？那是单核！还得是没有超线程的古董 CPU。在我的双核 CPU 上，这个死循环只会吃掉我一个核的工作负荷，也就是只占用 50％ CPU。那如何能让它在双核机器上占用 100％ 的 CPU 呢？答案很容易想到，用两个线程就行了，线程不正是并发分享 CPU 运算资源的吗。可惜答案虽然对了，但做起来可没那么简单。下面的程序在主线程之外又起了一个死循环的线程
import threadingdef dead_loop(): while True: pass# 新起一个死循环线程t = threading.Thread(target=dead_loop)t.start()# 主线程也进入死循环dead_loop()t.join()
按道理它应该能做到占用两个核的 CPU 资源，可是实际运行情况却是没有什么改变，还是只占了 50％ CPU 不到。这又是为什么呢？难道 python 线程不是操作系统的原生线程？打开 system monitor 一探究竟，这个占了 50% 的 python 进程确实是有两个线程在跑。那这两个死循环的线程为何不能占满双核 CPU 资源呢？其实幕后的黑手就是 GIL。
GIL 的迷思：痛并快乐着
GIL 的全称为Global Interpreter Lock，意即全局解释器锁。在 Python 语言的主流实现 CPython 中，GIL 是一个货真价实的全局线程锁，在解释器解释执行任何 Python 代码时，都需要先获得这把锁才行，在遇到 I/O 操作时会释放这把锁。如果是纯计算的程序，没有 I/O 操作，解释器会每隔 100 次操作就释放这把锁，让别的线程有机会执行（这个次数可以通过sys.setcheckinterval来调整）。所以虽然 CPython 的线程库直接封装操作系统的原生线程，但 CPython 进程做为一个整体，同一时间只会有一个获得了 GIL 的线程在跑，其它的线程都处于等待状态等着 GIL 的释放。这也就解释了我们上面的实验结果：虽然有两个死循环的线程，而且有两个物理 CPU 内核，但因为 GIL 的限制，两个线程只是做着分时切换，总的 CPU 占用率还略低于 50％。
看起来 python 很不给力啊。GIL 直接导致 CPython 不能利用物理多核的性能加速运算。那为什么会有这样的设计呢？我猜想应该还是历史遗留问题。多核 CPU 在 1990 年代还属于类科幻，Guido van Rossum 在创造 python 的时候，也想不到他的语言有一天会被用到很可能 1000＋ 个核的 CPU 上面，一个全局锁搞定多线程安全在那个时代应该是最简单经济的设计了。简单而又能满足需求，那就是合适的设计（对设计来说，应该只有合适与否，而没有好与不好）。怪只怪硬件的发展实在太快了，摩尔定律给软件业的红利这么快就要到头了。短短 20 年不到，代码工人就不能指望仅仅靠升级 CPU 就能让老软件跑的更快了。在多核时代，编程的免费午餐没有了。如果程序不能用并发挤干每个核的运算性能，那就意谓着会被淘汰。对软件如此，对语言也是一样。那 Python 的对策呢？
Python 的应对很简单，以不变应万变。在最新的 python 3 中依然有 GIL。之所以不去掉，原因嘛，不外以下几点：
欲练神功，挥刀自宫：
CPython 的 GIL 本意是用来保护所有全局的解释器和环境状态变量的。如果去掉 GIL，就需要多个更细粒度的锁对解释器的众多全局状态进行保护。或者采用 Lock-Free 算法。无论哪一种，要做到多线程安全都会比单使用 GIL 一个锁要难的多。而且改动的对象还是有 20 年历史的 CPython 代码树，更不论有这么多第三方的扩展也在依赖 GIL。对 Python 社区来说，这不异于挥刀自宫，重新来过。
就算自宫，也未必成功：
有位牛人曾经做了一个验证用的 CPython，将 GIL 去掉，加入了更多的细粒度锁。但是经过实际的测试，对单线程程序来说，这个版本有很大的性能下降，只有在利用的物理 CPU 超过一定数目后，才会比 GIL 版本的性能好。这也难怪。单线程本来就不需要什么锁。单就锁管理本身来说，锁 GIL 这个粗粒度的锁肯定比管理众多细粒度的锁要快的多。而现在绝大部分的 python 程序都是单线程的。再者，从需求来说，使用 python 绝不是因为看中它的运算性能。就算能利用多核，它的性能也不可能和 C/C++ 比肩。费了大力气把 GIL 拿掉，反而让大部分的程序都变慢了，这不是南辕北辙吗。
难道 Python 这么优秀的语言真的仅仅因为改动困难和意义不大就放弃多核时代了吗？其实，不做改动最最重要的原因还在于：不用自宫，也一样能成功！
- extern"C"{ void DeadLoop() { while (true); }}
- from ctypes import *from threading import Threadlib = cdll.LoadLibrary("libdead_loop.so")t = Thread(target=lib.DeadLoop)t.start()lib.DeadLoop()
- extern"C"{ typedef void Callback(); void Call(Callback* callback) { callback(); }}
- from ctypes import *from threading import Threaddef dead_loop(): while True: passlib = cdll.LoadLibrary("libcall.so")Callback = CFUNCTYPE(None)callback = Callback(dead_loop)t = Thread(target=lib.Call, args=(callback,))t.start()lib.Call(callback)
其它神功
那除了切掉 GIL 外，果然还有方法让 Python 在多核时代活的滋润？让我们回到本文最初的那个问题：如何能让这个死循环的 Python 脚本在双核机器上占用 100％ 的 CPU？其实最简单的答案应该是：运行两个 python 死循环的程序！也就是说，用两个分别占满一个 CPU 内核的 python 进程来做到。确实，多进程也是利用多个 CPU 的好方法。只是进程间内存地址空间独立，互相协同通信要比多线程麻烦很多。有感于此，Python 在 2.6 里新引入了multiprocessing这个多进程标准库，让多进程的 python 程序编写简化到类似多线程的程度，大大减轻了 GIL 带来的不能利用多核的尴尬。
这还只是一个方法，如果不想用多进程这样重量级的解决方案，还有个更彻底的方案，放弃 Python，改用 C/C++。当然，你也不用做的这么绝，只需要把关键部分用 C/C++ 写成 Python 扩展，其它部分还是用 Python 来写，让 Python 的归 Python，C 的归 C。一般计算密集性的程序都会用 C 代码编写并通过扩展的方式集成到 Python 脚本里（如 NumPy 模块）。在扩展里就完全可以用 C 创建原生线程，而且不用锁 GIL，充分利用 CPU 的计算资源了。不过，写 Python 扩展总是让人觉得很复杂。好在 Python 还有另一种与 C 模块进行互通的机制 : ctypes
利用 ctypes 绕过 GIL
ctypes 与 Python 扩展不同，它可以让 Python 直接调用任意的 C 动态库的导出函数。你所要做的只是用 ctypes 写些 python 代码即可。最酷的是，ctypes 会在调用 C 函数前释放 GIL。所以，我们可以通过 ctypes 和 C 动态库来让 python 充分利用物理内核的计算能力。让我们来实际验证一下，这次我们用 C 写一个死循环函数
用上面的 C 代码编译生成动态库libdead_loop.so（Windows 上是dead_loop.dll）
，接着就要利用 ctypes 来在 python 里 load 这个动态库，分别在主线程和新建线程里调用其中的DeadLoop
这回再看看 system monitor，Python 解释器进程有两个线程在跑，而且双核 CPU 全被占满了，ctypes 确实很给力！需要提醒的是，GIL 是被 ctypes 在调用 C 函数前释放的。但是 Python 解释器还是会在执行任意一段 Python 代码时锁 GIL 的。如果你使用 Python 的代码做为 C 函数的 callback，那么只要 Python 的 callback 方法被执行时，GIL 还是会跳出来的。比如下面的例子：
注意这里与上个例子的不同之处，这次的死循环是发生在 Python 代码里 (DeadLoop函数) 而 C 代码只是负责去调用这个 callback 而已。运行这个例子，你会发现 CPU 占用率还是只有 50％ 不到。GIL 又起作用了。
其实，从上面的例子，我们还能看出 ctypes 的一个应用，那就是用 Python 写自动化测试用例，通过 ctypes 直接调用 C 模块的接口来对这个模块进行黑盒测试，哪怕是有关该模块 C 接口的多线程安全方面的测试，ctypes 也一样能做到。
结语
虽然 CPython 的线程库封装了操作系统的原生线程，但却因为 GIL 的存在导致多线程不能利用多个 CPU 内核的计算能力。好在现在 Python 有了易经筋（multiprocessing）, 吸星大法（C 语言扩展机制）和独孤九剑（ctypes），足以应付多核时代的挑战，GIL 切还是不切已经不重要了，不是吗。