@dongyuanxun，好的，谢谢

改改改改改

http://tangtocnet.com/index.php?showtopic=3514&st=0

這版本的FF 好像也很快

sunspider :263.4ms+/-1.1%

有提供mozconfig和编译方法么？

ps：编译thunderbird5把我搞郁闷了，也不是编译有难度吧，而是他一到pgo测试那里就不启动它本身测试，而是启动的我系统中的firefox…… 这个是什么情况，要修改什么么……
我准备给tete009发email问一下具体编译流程再进行。

thunderbird5编译成功
http://pcxfirefox.googlecode.com/files/ ... emalloc.7z

dongyuanxun：
-O2改为-O3 （-O3有函数内联）
增加开关 -ffast-math -fivopts -ftree-loop-linear -ftree-vectorize -fforce-addr  -fno-bounds-check
在自动向量化方面增加-mmmx -msse -msse2 -msse3

修改pgo最简单的方法是修改/build/pgo里面的index.html里面的链接和延迟时间，最好改延迟时间吧，因为你改的长了，pgo测试结束时间也长，所以在这期间你可以自行运行其他项目，我的源码删除了，所以不记得修改具体哪个位置了。回到原帖

Gentoo里设置-O3编译FF有点麻烦，我没用启用。你推荐的gcc选项-ffast-math -fivopts -ftree-loop-linear -ftree-vectorize都不太安全，虽然编译成功了，但网页里显示图片的时候会有很多白色横线，所以我没用这些。你说O3打开了内联函数，所以我加上了finline-functions -funswitch-loops，编译后Sunspider没有提升，Google V8提高了100ms左右，但生成的软件包也由10.9MB变成了11.6MB。至于PGO测试，我也打开了我常上了网站youku等，但测试结果显示PGO版本相比无PGO的版本没用什么提升。

所以我得出结论，Linux下FireFox的PGO优化意义不大。

Gentoo里设置-O3编译FF有点麻烦，我没用启用。你推荐的gcc选项-ffast-math -fivopts -ftree-loop-linear -ftree-vectorize都不太安全，虽然编译成功了，但网页里显示图片的时候会有很多白色横线，所以我没用这些。你说O3打开了内联函数，所以我加上了finline-functions -funswitch-loops，编译后Sunspider没有提升，Google V8提高了100ms左右，但生成的软件包也由10.9MB变成了11.6MB。至于PGO测试，我也打开了我常上了网站youku等，但测试结果显示PGO版本相比无PGO的版本没用什么提升。

所以我得出结论，Linux下FireFox的PGO优化意义不大。

不安全的选项为-ffast-math，其他还是比较正常的。因为VC的GL（相当于gcc的lto）对pgo影响巨大，所以这个也有关系。

dongyuanxun：
有提供mozconfig和编译方法么？

ps：编译thunderbird5把我搞郁闷了，也不是编译有难度吧，而是他一到pgo测试那里就不启动它本身测试，而是启动的我系统中的firefox…… 这个是什么情况，要修改什么么……
我准备给tete009发email问一下具体编译流程再进行。回到原帖

个人猜测，它测试的是xulrunner

编译firefox pgo时，将xulrunner分离出来，应该也是如此

gcc除了针对硬件的优化选项，能提升明显的性能外
其余的个人觉得完全没有必要....

havanna：gcc除了针对硬件的优化选项，能提升明显的性能外
其余的个人觉得完全没有必要....回到原帖

不是的，-march/-mtune检测不准，-msse2等会在编译开关中自动加入define __SSE2__等，这样ff中很多针对这些重写的代码就有了用武之地（大部分在jpeg解析上，因为他用了jpegturbo） 其他如-ftree-vectorize可以使得循环优化的更好些，4.5之后当然还有自动并行的开关，如果你的循环无依赖，用这个有明显的提升（-ftree-parallelize-loops=n，n为你的cpu核心数）。
其他链接型优化就是lto了，这个对pgo的影响还是很大的，gcc不加lto时，pgo只对某一个obj分支判断、循环展开进行适当的优化，加入lto后才会在全局考虑。不过lto的bug较多，4.5的gcc要自己移植4.6的补丁，4.6之后的gcc至少要关注bugzilla的关于lto的一系列进展，及时的把链接错误的补丁打上。按现在来看，lto在最新的gcc4.6.1 release上还是表现良好的，只有lto 插件（对静态链接库有用）有些bug。lto的最大缺点是，链接时间非常长，消耗内存很多（比vc的GL还要多很多），使用之前先想想内存够用否。
-ffast-math这个违反ieee浮点精度提升来的，所以有适用范围，发现不良现象后要及时废弃掉。
对共享库加入-fvisibility=hidden -fvisibility-inlines-hidden，也有减小共享库大小的作用，当然也节省了内存。
-mfpmath=sse这个开关慎用，gcc对这个开关一直有问题，用了之后，浮点运算反而会计算的慢。
反正gcc的开关众多，使用时要慢慢体验。平常使用最多的就是-O2/-O3  内联 -march/-mtune -mmmx -msse -msse2，其他有些开关已经在-O3中包含。

LZ 真有研究  
4.6 我一般Ofast 了结  
不折腾

dongyuanxun：
不是的，-march/-mtune检测不准，-msse2等会在编译开关中自动加入define __SSE2__等，这样ff中很多针对这些重写的代码就有了用武之地（大部分在jpeg解析上，因为他用了jpegturbo） 其他如-ftree-vectorize可以使得循环优化的更好些，4.5之后当然还有自动并行的开关，如果你的循环无依赖，用这个有明显的提升（-ftree-parallelize-loops=n，n为你的cpu核心数）。
其他链接型优化就是lto了，这个对pgo的影响还是很大的，gcc不加lto时，pgo只对某一个obj分支判断、循环展开进行适当的优化，加入lto后才会在全局考虑。不过lto的bug较多，4.5的gcc要自己移植4.6的补丁，4.6之后的gcc至少要关注bugzilla的关于lto的一系列进展，及时的把链接错误的补丁打上。按现在来看，lto在最新的gcc4.6.1 release上还是表现良好的，只有lto 插件（对静态链接库有用）有些bug。lto的最大缺点是，链接时间非常长，消耗内存很多（比vc的GL还要多很多），使用之前先想想内存够用否。
-ffast-math这个违反ieee浮点精度提升来的，所以有适用范围，发现不良现象后要及时废弃掉。
对共享库加入-fvisibility=hidden -fvisibility-inlines-hidden，也有减小共享库大小的作用，当然也节省了内存。
-mfpmath=sse这个开关慎用，gcc对这个开关一直有问题，用了之后，浮点运算反而会计算的慢。
反正gcc的开关众多，使用时要慢慢体验。平常使用最多的就是-O2/-O3  内联 -march/-mtune -mmmx -msse -msse2，其他有些开关已经在-O3中包含。回到原帖

gcc-4.6.1我还没有上，之前上4.6.0，打开lto编译了一大堆包，结果性能没有提升，生成的binary大了许多，所以我退回了gcc-4.5.2.

Firefox PGO我暂时不折腾了，估计就算打开lto编译成功，性能提升也很有限，毕竟我现在在Gentoo下未开启PGO和lto所编译出来的FF比你的版本也就只差一点(SunSpider).

改改改改改

FESE II http://tangtocnet.com/index.php?showtopic=4513

给出这个成绩没啥说服力啊，每个人的电脑配置都不一样……
可以在你的电脑上比较各个版本的，sunspider我感觉各个版本差别不大吧

fiey：LZ 真有研究  
4.6 我一般Ofast 了结  
不折腾回到原帖

-Ofast=-O3 -ffast-math
后一个开关有时候会出错误结果，遇到时可以注意下。

gcc-4.6.1我还没有上，之前上4.6.0，打开lto编译了一大堆包，结果性能没有提升，生成的binary大了许多，所以我退回了gcc-4.5.2.

Firefox PGO我暂时不折腾了，估计就算打开lto编译成功，性能提升也很有限，毕竟我现在在Gentoo下未开启PGO和lto所编译出来的FF比你的版本也就只差一点(SunSpider).

我感觉你用错了，lto编译是个两步开关，即在编译期间和链接期间都要加入这个开关，如果你只在编译期间加了，那么就会生成的大很多而且性能也和没加时一样。
另外一个lto插件开关仅在链接期间加入。