玩命式编译内核

d00m3d

Post by ti8er;1914100
自己写驱动程序来优化内核算了。Linux下的驱动并不很难写，不过要有硬件手册做对照：）

如何写？愿闻其详。。。

ti8er

Post by d00m3d;1914263
如何写？愿闻其详。。。

硬件驱动无非是给硬件的端口写入相应的东西，然后硬件就会工作，然后从另一个端口得到东西。

Linux下之所以驱动比Windows好编，是因为它把所有的硬件都看成文件来对待，一个fopen()函数就可以万能地读写所有的文件，也可以读写所有的硬件，非常地统一。

我以前在学校时用汇编语言和C写过一段驱动，用来让二极管和喇叭工作的，比较简单，其实可以当作是初级的显卡和声卡驱动了。不过很久没动了，都退化了。现在我只知道相关的大原理，只能纸上谈兵，自己可写不来了，呵呵。

至于CPU优化，大体上就是给内核增加相应的CPU指令，这个好像是在内核的CPU头文件那里定义的，可以在那个地方把缺的指令加上就可以了。要是熟练的话也可以自己写CPU驱动出来，然后编译到内核中。

毁灭兄那么牛，应该能搞定的。我现在不行啦

qufo

昨天回家试了一下-O3编译，内核比-O2增加了0.1M，速度的话，因为没有测试，所以目前感觉不出来。

hritian

Post by goodstarting;1913707
d00m3d 斑竹您确定采用-O3能提速？

个人在您的提示下尝试清空源码树修改Makefile，将其中的-O2改为-O3
可以编译模块，没有提示错误（或许这个在28内核中改进了没出错？）

察看了bzImage体积增大了点（原先用-Os出来的是1.3M，用-O3出来的是1.7M）
可速度方面好像没什么提升

或许我感觉不对

gentoo上面说在gcc4.0以后o3的效果并不大。
http://www.gentoo.org/doc/en/gcc-optimization.xml

In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x. Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x.

qufo

Post by hritian;1914667
gentoo上面说在gcc4.0以后o3的效果并不大。
http://www.gentoo.org/doc/en/gcc-optimization.xml

In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x. Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x.

我的内核是 2.9M
我还以为比起 40M来说很小了，没想到还搞成 1.x M,
无所谓，我内存多，费得起。

d00m3d

Post by hritian;1914667
gentoo上面说在gcc4.0以后o3的效果并不大。
http://www.gentoo.org/doc/en/gcc-optimization.xml

In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x. Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x.

效果的大小属个人理解而矣，近日测试 2.6.28-rc6、rc7 及 rc7-git7 都能直接通过-O3 了，可惜用 gcc-4.4 的 snapshot 仍然有问题

至於数据，我用 scimark2 对比过，-O3 的内核的确要比 -O2 快，数据待我整理好後再贴出来

trublemaker

http://gcc.gnu.org/ml/gcc/2004-03/msg00634.html

大家用这个例子试一下，O2和O3的性能差异还是比较大的，
当然，这个例子是针对浮点数的。

hritian

Post by d00m3d;1923524
效果的大小属个人理解而矣，近日测试 2.6.28-rc6、rc7 及 rc7-git7 都能直接通过-O3 了，可惜用 gcc-4.4 的 snapshot 仍然有问题

至於数据，我用 scimark2 对比过，-O3 的内核的确要比 -O2 快，数据待我整理好後再贴出来

相当期待测试数据。

不过我最近测服务器的数据来看，我倒是觉得glibc的编译优化效果很好，内核优化倒是没看到什么很明显的效果。

shooter

lz就好像在玩F1，速度快，过瘾，不过很容易撞车，汽车也很容易出故障~

d00m3d

Post by hritian;1924750
相当期待测试数据。

不过我最近测服务器的数据来看，我倒是觉得glibc的编译优化效果很好，内核优化倒是没看到什么很明显的效果。

这是 linux-2.6.28rc6 内核利用不同的优化编译後由 SciMark2 C-version 的数据，以标准测试为例，两者平均值相差大概是 1.85 MFlops（百万次浮点运算），实际运作大概於 0.1-0.2 秒之间，不容易察觉，所以跑一些比较消耗资源的软件便明显一些

刚看一下 top500，今天的超级太 BT 了，IBM 的 Roadrunner 已超越 PFlops (1000 TFlops) 之谱，偶的老机子连 GFlops 都不到 ：（

Btw，中国也可以引以为敖，上海超级电脑在最新 Top500 排名现时第十位

http://www.top500.org/list/2008/11/100