Lawliet
火狐狸
火狐狸
  • UID34414
  • 注册日期2010-11-03
  • 最后登录2017-04-02
  • 发帖数201
  • 经验13枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 社区居民
  • 忠实会员
阅读:7639回复:30

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

楼主#
更多 发布于:2011-12-13 19:44
我目前已經遇到這個問題
編譯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
fiey
非常火狐
非常火狐
  • UID28955
  • 注册日期2009-05-24
  • 最后登录2013-10-05
  • 发帖数735
  • 经验10枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
1楼#
发布于:2011-12-13 19:44
虽然浏览器本身还没碰到内存瓶颈
这编译已经提前碰到了
64bit时代
128bit 大概看不到了
dongyuanxun
非常火狐
非常火狐
  • UID28632
  • 注册日期2009-04-19
  • 最后登录2013-02-14
  • 发帖数898
  • 经验10枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
2楼#
发布于:2011-12-13 19:44
反正在不改组件编译方式的前提下(把链接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有什么问题。
Lawliet
火狐狸
火狐狸
  • UID34414
  • 注册日期2010-11-03
  • 最后登录2017-04-02
  • 发帖数201
  • 经验13枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 社区居民
  • 忠实会员
3楼#
发布于:2011-12-13 19:44
意思是VC2005還不會遇到這個問題嗎?
如果是我將編譯環境改成VC2005是否能完成編譯?
因為我前幾次編譯的結果,問題似乎出在XUL部分上
想過分開來單獨先編譯XUL的部份,然後再拿來用
只是還未試過,不知是否可行?

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

另外我還看了MSDN上的QA
似乎微軟有意在VS2011上解決這個問題還有PGO優化問題
dongyuanxun
非常火狐
非常火狐
  • UID28632
  • 注册日期2009-04-19
  • 最后登录2013-02-14
  • 发帖数898
  • 经验10枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
4楼#
发布于:2011-12-13 19:44
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)。
Lawliet
火狐狸
火狐狸
  • UID34414
  • 注册日期2010-11-03
  • 最后登录2017-04-02
  • 发帖数201
  • 经验13枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 社区居民
  • 忠实会员
5楼#
发布于:2011-12-13 19:44
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
如果沒辦法優化,或許我就不編譯了
dongyuanxun
非常火狐
非常火狐
  • UID28632
  • 注册日期2009-04-19
  • 最后登录2013-02-14
  • 发帖数898
  • 经验10枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
6楼#
发布于:2011-12-13 19:44
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)
Lawliet
火狐狸
火狐狸
  • UID34414
  • 注册日期2010-11-03
  • 最后登录2017-04-02
  • 发帖数201
  • 经验13枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 社区居民
  • 忠实会员
7楼#
发布于:2011-12-13 19:44
我下載了,目前具體移植情況如何?
是可用的程度了嗎?

要不我來幫您測試gcc編譯win32版Firefox PGO的情形吧
kmc
kmc
管理员
管理员
  • UID165
  • 注册日期2004-11-25
  • 最后登录2022-09-22
  • 发帖数9186
  • 经验397枚
  • 威望1点
  • 贡献值124点
  • 好评度41点
  • 忠实会员
  • 终身成就
  • 社区居民
8楼#
发布于:2011-12-13 19:44
我今天下午看的时候标题还是64位难产,现在32位也生不出来了?
Waterfox Current和Firefox Nightly都用,逐渐走出XUL扩展依赖
Lawliet
火狐狸
火狐狸
  • UID34414
  • 注册日期2010-11-03
  • 最后登录2017-04-02
  • 发帖数201
  • 经验13枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 社区居民
  • 忠实会员
9楼#
发布于:2011-12-13 19:44
kmc:我今天下午看的时候标题还是64位难产,现在32位也生不出来了?回到原帖

沒改過標題啊,以前是64bit難產
現在兩邊都難產了
aeneid
火狐狸
火狐狸
  • UID24252
  • 注册日期2008-05-22
  • 最后登录2016-01-16
  • 发帖数260
  • 经验47枚
  • 威望0点
  • 贡献值14点
  • 好评度1点
  • 社区居民
  • 忠实会员
10楼#
发布于:2011-12-13 19:44
一直在用楼主的9.0b3编译版,期待更新
GOLF-AT
千年狐狸
千年狐狸
  • UID11611
  • 注册日期2006-02-20
  • 最后登录2019-12-30
  • 发帖数3239
  • 经验265枚
  • 威望1点
  • 贡献值260点
  • 好评度59点
  • 社区居民
  • 忠实会员
11楼#
发布于:2011-12-13 19:44
今天看到一个报道,提到了这个问题,目前要精简,暂时去掉一些东西。
asdfcc
火狐狸
火狐狸
  • UID31778
  • 注册日期2010-01-25
  • 最后登录2020-04-20
  • 发帖数181
  • 经验45枚
  • 威望0点
  • 贡献值0点
  • 好评度1点
12楼#
发布于:2011-12-13 19:44
贴个中文版的出来,关评网上看到的:

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

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

同时Mozilla也正在考虑分拆libxul部分,对其中的核心代码进行分组,例如Direct3D之上的WebGL、媒体库等组件可以分开编译。
asdf123456
千年狐狸
千年狐狸
  • UID32588
  • 注册日期2010-04-16
  • 最后登录2020-02-17
  • 发帖数1088
  • 经验299枚
  • 威望0点
  • 贡献值50点
  • 好评度10点
  • 社区居民
  • 忠实会员
13楼#
发布于:2011-12-13 19:44
微软这个崴货,还是开源的东西强大,GCC给力呀!
dongyuanxun
非常火狐
非常火狐
  • UID28632
  • 注册日期2009-04-19
  • 最后登录2013-02-14
  • 发帖数898
  • 经验10枚
  • 威望0点
  • 贡献值0点
  • 好评度0点
14楼#
发布于:2011-12-13 19:44
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位版测试
上一页
游客

返回顶部