32bit的Firefox PGO似乎會越來越難產了

我目前已經遇到這個問題
編譯9.0beta偶爾會發生error LNK
編譯時間與需要的記憶體明顯提高
在Bugzilla上有看到改用64bit編譯器
來編譯32bit Firefox PGO的方法
不過我並未嘗試

而tete009使用VS2005，似乎也必須放棄轉到VS2010
否則記憶體需求超過3GB時，就會發生error LNK

http://news.softpedia.com/news/Firefox- ... 0112.shtml
http://www.h-online.com/open/news/item/ ... 93772.html

虽然浏览器本身还没碰到内存瓶颈
这编译已经提前碰到了
64bit时代
128bit 大概看不到了

反正在不改组件编译方式的前提下（把链接xul中比较大的模块弄成动态链接），这个目前来说无解

另外，微软并不提供64bit到32bit的交叉link（host为64bit，target为32bit），所以不可能使用64位的工具来操作32bit的链接
微软目前只提供32bit到64bit的交叉link，亦即在32位环境中产生64位程序。所以我觉得你在bugzilla看到的是错误的说法或者是误解。

tete009的补丁明显可以在VC2010里用，只不过VC2005产生的obj要小（link需要的内存和obj总和有关），所以界限比VC2010要宽松

我为什么想在将来放弃使用VC来编译ff而使用mingw(64)gcc，链接溢出也是一个原因，gcc你可以随便编译出host64，target32的东西来。
一旦gcc的链接消去开关移植成功就可以开始尝试编译了，再看看lto会不会有什么问题，最后看看pgo有什么问题。

意思是VC2005還不會遇到這個問題嗎？
如果是我將編譯環境改成VC2005是否能完成編譯？
因為我前幾次編譯的結果，問題似乎出在XUL部分上
想過分開來單獨先編譯XUL的部份，然後再拿來用
只是還未試過，不知是否可行？

我在gcc 4.6.2上編譯並加上lto開關
貌似會失敗，而且我發現了源碼內的python腳本有些問題
必須修改才能夠進行內建的自動PGO優化過程
否則編譯會自動強制退出

另外我還看了MSDN上的QA
似乎微軟有意在VS2011上解決這個問題還有PGO優化問題

VC2005显然会啊，只不过obj的大小还没到界限而已，随着Firefox模块的增加（鬼知道未来还要加什么标准协议），溢出是早晚的事

mozilla的makefile都是使用FORCE_STATIC_LIB和FORCE_SHARED_LIB来实现到底是静态还是动态链接
可以参见https://developer.mozilla.org/en/FORCE_SHARED_LIB
tete009是把mozlibpixman分离了出来，不过这个模块本身就不大

另外一个方式是在一些性能不重要的地方把-GL开关禁用掉，比如界面之类的，加入-GL-也会大大减小obj的体积，虽然有一定的性能损失。

Linux下没必要使用第三方编译，官方的就不错，一般在Linux下都是教学和学习，重视性能的地方很少。
但在Windows下，MinGW(64)是一个可选，不过得弄的更稳定才行。现在其实就可以构建了，但是体积有些大，我想在移植链接消去开关成功后再去弄（不过这对obj的体积又是个考验，所以必须使用多target/mutiple lib了）。

VC2011都不知道啥时了，而且到时还编译不出jemalloc，还得再改改，也不知道稳定性会如何，微软的版本是出了名的第一个版本很差的那种…… 所以我认为，都转到GCC才是最终的解决方案，不过这个需要时间（解决几个关键性的bug）。

linux下現在還可以用LLVM 3.0編譯，似乎也可以移植到windows上來
http://www.phoronix.com/scan.php?page=a ... g_30&num=3

而且完全不必patch gcc4.6就可以在作為gcc的前端
看了性能測試，LLVM 3.0相較於gcc，這回優勢是比較明顯
我先前在linux下編譯Firefox，不開lto的情況下
性能雖然不及win32版，但使用體驗以及那個流暢性
完全不是win32版可以媲美的

我現在在等Firefox 9.0 release
如果沒辦法優化，或許我就不編譯了

llvm早就可以在Windows下编译了，最近我把DragonEgg 3.0的插件也移植到Windows上来：http://code.google.com/p/pcxllvm/downloads/list  这个算全球首发的吧
我不知道他们llvm和gcc是如何测试的，跟据我用的测试用例，在默认开关下（-O2和-O3），llvm在某些项目上比gcc快，有些也慢，不过在同时开了其他也比较常用的优化开关后（TARGET/SIMD/LTO/PGO等），llvm在所有项目上都落后于gcc了（除了编译时间），而且落后幅度较大。

Windows的Firefox改成gcc编译后，体验如何不好说，还得再观察。不过我用的其他项目转到gcc编译后倒是没发现有什么问题。
暂时还没有人尝试做这个，所以我没有进度表。（可能先交叉编译，这样编译链接速度快3-4倍，不过交叉编译无法pgo）

我下載了，目前具體移植情況如何？
是可用的程度了嗎？

要不我來幫您測試gcc編譯win32版Firefox PGO的情形吧

我今天下午看的时候标题还是64位难产，现在32位也生不出来了？

kmc：我今天下午看的时候标题还是64位难产，现在32位也生不出来了？回到原帖

沒改過標題啊，以前是64bit難產
現在兩邊都難產了

一直在用楼主的9.0b3编译版，期待更新

今天看到一个报道，提到了这个问题，目前要精简，暂时去掉一些东西。

贴个中文版的出来，关评网上看到的：

Mozilla Firefox团队最近发现了一个非常棘手的问题，那就是Firefox由于代码过于臃肿无法可靠地被编译，因为linker的运行超出了虚拟地址空间。
问题的根源是Firefox是一款只能工作在32位系统下的程序，而无法访问3GB以上的物理内存。

这已经不是Mozilla第一次遇到这种问题，数年前2GB的虚拟地址空间限制就让他们犯难，而这次就不能用物理地址扩展的方法来实现，因此解决方案只有两个，要么优化代码甚至减少组件（目前正在这么做，Graphite, SPDY, libreg等新功能正在被暂时移除），要么转换到64位架构和机器进行编译，这样就可以访问4GB以上的地址空间。

同时Mozilla也正在考虑分拆libxul部分，对其中的核心代码进行分组，例如Direct3D之上的WebGL、媒体库等组件可以分开编译。

微软这个崴货，还是开源的东西强大，GCC给力呀！

Lawliet：我下載了，目前具體移植情況如何？
是可用的程度了嗎？

要不我來幫您測試gcc編譯win32版Firefox PGO的情形吧回到原帖

由于Windows下GCC不具有rdynamic的特性，所以只能使用固定动态连接库的形式
看我里面的说明
gcc 使用cc1的dll
g++ 使用cc1plus的dll
gfortran 使用f951的dll

其他情形和DragonEgg的使用方式一样
由于Linux的Gold链接器暂时不可能移植到Windows上来（我准备弄完链接消去弄这个），所以使用DragonEgg时如果用到LTO功能要和LLVM的组件一起配合使用，这个在DragonEgg的主页上有说明。
以我现有的项目，使用DragonEgg/LLVM/Clang编译没发现什么问题，但没遇到Firefox这种复杂情形

GCC我暂时还没有时间编译64位版，所以你如果采用LTO方式的话很可能也会出现链接溢出的情况，64位混合版我一年只编译一个，力求最稳定。当我32位版的补丁经过长时间的测试没有问题的话，会开始编译64位版测试