Firefox、バイナリサイズが大きくなりすぎて 32 ビット Windows では最適化ビルドできなくなる 91
ストーリー by reo
山椒魚 部門より
山椒魚 部門より
ある Anonymous Coward 曰く、
最近活発なリリースが行われている Firefox であるが、バイナリのサイズが大きくなりすぎたため、32 ビット Windows ではリンク時のガイド付き最適化 (PGO) がメモリ不足で実行できなくなっているそうだ (mozilla.dev.platform グループへの投稿、本家 /. 記事より) 。
32 ビット版 Windows は最大 3 GB までしかメモリを利用できないが、PGO ではこれ以上のメモリが必要になってしまったそうだ。いまのところは inbound ブランチだけの問題で「64 ビット版 Windows でビルドする」などいくつかの解決策が提案されている。
Windows 2000への対応打ち切りって事？ (スコア:2)
十分なメモリを扱えるリンカだと、対応バイナリを吐けないから。
Re:Windows 2000への対応打ち切りって事？ (スコア:2, 参考になる)
本家で中の人がコメントしてたけど、打ち切りたくないからVS2010に移行したりはできないんだってさ。
VS2010でリンクするとXPSP2以上が必要になるとか。
Re:Windows 2000への対応打ち切りって事？ (スコア:2)
見てきた感じ、リンカではなくCRTだけの問題なのかも。
Re:Windows 2000への対応打ち切りって事？ (スコア:1)
WindowsXPでは、PentiumPro辺りで追加された拡張命令を積極的に使うようになった。
それに伴って、地味に有用なAPIが追加されてる。
こいつらの使用有無で、Windows2000対応の可否が決まる。
例え使って無くても、XPにしかないAPIへのリンクが有ると、そのCRTは2000で動かない。
そして、VS2008以降に付属のCRTはそのリンクを持ってるから、ビルドすると2000対応が無くなる。
目立たないけど、意外に大きな壁が、2000とXPの間に在るんだよね。
-- Buy It When You Found It --
Re:Windows 2000への対応打ち切りって事？ (スコア:1)
Re:Windows 2000への対応打ち切りって事？ (スコア:1)
PAEやDEPの様な派手なのじゃなく、排他制御関係のひたすら地味な拡張ね。
シングルプロセッサなら割り込みを禁止するだけで済む様な操作も、マルチプロセッサではCPU間の排他制御が必須。
これがPentiumProで結構強化されてる。
-- Buy It When You Found It --
Re:Windows 2000への対応打ち切りって事？ (スコア:1)
>目立たないけど、意外に大きな壁が、2000とXPの間に在るんだよね。
というなら、
「Win2KはPC-98ｘ1版もある」ほうが大きいですよ。
もちろんPC-98x1は動作保証外と書くこともできますが、
知らない人が買ってって怒ってクレームしてきたり、
PC-98x1自体よく分からない人が敬遠して購入しなくなったりします。
結局、Win2Kでも動作するアプリなのにPC-98ｘ１を外すためにWinXP以降対応にする、
というアプリが数多く。
いい機会だから、Win4.0でも動くmsvcr100を (スコア:1)
訂正: 5.0可 (スコア:1)
嘘つきました、5.0にはできました。4.0は無理。 > LNK4010
あと無改行御免
古いOSを無理やり使い続ける奴ら (スコア:1)
＞インターネット環境用に古いOSを無理やり使い続ける奴らが根絶せず
呼んだ？ｗｗｗ
Build identifier: Mozilla/5.0 (OS/2; Warp 4.5; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
しかし Firefox が Win 2K サポートを止めても、Opera [opera.com] に乗り換えられるだけじゃないかな。
Re: (スコア:0)
いや、もうWin2Kはネットつなぐなよ
Re:Windows 2000への対応打ち切りって事？ (スコア:1)
僕の研究室の教授に言って欲しいです。
#2k使わされてるからAC
Re: (スコア:0)
Firefox 9 システム要件では、Windows 2000対応です。
http://mozilla.jp/firefox/9.0/system-requirements/ [mozilla.jp]
リンカーだけでなく (スコア:2)
MicrosoftのPGOはリンカーだけでなく
/O1と/O2で適用される最適化項目の多くにフィードバックされたと思います。
（メモリ不足には、中間 COMDAT の除去も影響しそう）
あと、SeaMonでは8月頃から既にメモリ不足が出ていた様です。
http://slashdot.jp/journal/537189 [slashdot.jp]
Re:リンカーだけでなく (スコア:2)
それを書いた当人ですが、それは、64ビット版link.exeのバグが原因で起きている現象 [microsoft.com]です。
それの回避策は32ビット版link.exeで代用することなのですが、今回の件はそれが使えなくなったということです。
Microsoft側の反応は「We have identified the cause and the bug will be fixed in a future release. 」とかいうものなので、
直るのはVisual Studio 11のときなのかもしれません。本音としては、この点を修正したVS10のSP2を出して欲しいところなのですが。
Re:リンカーだけでなく (スコア:1)
おそらく Firefox のビルドをしていてこの問題に気が付いたのでしょう。
という訳でこの問題を一番手っ取り早く解決できるのは Microsoft というのは正しそうです。
PAEとラージページ使わないのか (スコア:1)
Re:PAEとラージページ使わないのか (スコア:1)
・足りないのは物理メモリではなく仮想アドレス空間です。ラージページで物理メモリを節約できても関係ありません。
・足りないのは実行時の(firefox.exeの)メモリではなくビルド時の(link.exeの)メモリです。改修できるのはMicrosoftだけです。
Re:PAEとラージページ使わないのか (スコア:1)
M$の開発体制 (スコア:1)
旧版Windowsでの動作を捨てて、最新のVisualStudioを使うと問題は生じない。
だから、新機能は新OSでしか提供されないのさ。
-- Buy It When You Found It --
Re: (スコア:0)
DLLとして分かれている部分が多いから問題となってないとかですかね
Re: (スコア:0)
>「64 ビット版 Windows でビルドする」などいくつかの解決策が提案されている。
この提案はWindowsにもそのまま適用できそうだけど。
あと、Microsoftの製品はdllの集合体みたいなイメージがある。
Re: (スコア:0)
あ、ラージページでカーネルがページテーブルに予約しているアドレス空間も節約できるかもしれませんが、足りないのはユーザー空間なのでどのみち関係ありません。
Re: (スコア:0)
え？
MSなら改修できるの？
Re:PAEとラージページ使わないのか (スコア:1)
MSがlink.exeでAWEを使うとか、メモリが足りなくなったら一時ファイルにスワップしてビルドを続行するとかの改修をlink.exeに行なってくれたらビルドできるようになるかもしれない。
それよりも、早く64bit版のlink.exeでまともにPGOビルドできるようにしてくれって感じだが。
Re: (スコア:0)
そういうやり方で3GB以上のメモリ空間を使えるようにしたとして、
最適ビルドに何日かかるんだよ。
Windows7/2008R2以降、ほとんど売れているのは64ビット版のWindows
なんだから、そこまでやるか？
俺だったらやらない。
Re:PAEとラージページ使わないのか (スコア:2)
OSが64bitになっててもpluginが32bitのままってのが多いからねぇ。IEも標準は32bitだし。
でもjavaとflashは64bit対応したし、そろそろ軸足を64bitに動かすのはありでしょうね。
ただ、32bit環境を切り捨てるにはまだ早すぎるでしょ。
Re:PAEとラージページ使わないのか (スコア:1)
Re:PAEとラージページ使わないのか (スコア:1)
さらに言うと、Memory Limits for Windows Releases [microsoft.com]の“User-mode virtual address space for each 32-bit process”の欄に書いてあるのですが、64ビットWindowsで32ビットアプリを動かすと（3GBからさらに増えて）4GB使えます。これがストーリー本文に書いてある「64 ビット版 Windows でビルドする」という解決策の言っている意味となります。
Re: (スコア:0)
なんでもマイクロソフトのせいとかギャグですか！
改修できるのはインテルじゃないの？
改修してできたのがx64アーキテクチャじゃないの？
Re:PAEとラージページ使わないのか (スコア:2)
Linuxは32ビットでも3GBの壁突破できたはず。
例えばUbuntuはPAE有効版あります。
＃コレでFireFoxのコンパイルできるのかどうかは知らない。
Re: (スコア:0)
Re: (スコア:0)
link.exeをIntelが作っているとは知りませんでした。
まともな64bitのlink.exeがないのも、AWEを使ったりメモリがなくなるとファイルにスワップする等して何とか続行したりしないでInternal Errorを吐いてlink.exeがコケるのもIntelのせいだったんですね。
VC 2010? (スコア:1)
1) Make libxul smaller - Either by removing code entirely or by splitting
things into separate shared libraries.
2) Move to MSVC 2010 - We know that changesets that reliably failed to link
on MSVC 2005 linked successfully with MSVC 2010. What we don't know is how
much this helps (I expect the answer is somewhere between a lot and a
little). We can't really do this for (at the bare minimum) a couple more
weeks anyways due to product considerations about what OSs we support.
3) Do our 32 bit builds on machines running a 64 bit OS. This will allow
the linker to use 4 GB of address space.
と2番目にVC 2010対応させることが書いてあるけど、2010にするとメモリ消費が抑えられたという何か実例があるのかな？
64ビットWindowsでビルドするのではなく (スコア:1)
共有ライブラリとしてDLLを使用する訳ではないので、DLL Hellのような問題は生じません。
当然、この場合全体的なプログラムの肥大化は止まりません。
L80.COM (遠い目) (スコア:1)
昔の CP/M とか MSX-DOS な L80.COM みたいなことで未だに悩まされるんですね... オンメモリでリンクするリンカは Microsoft の習い性なのかしらん？ (確かに実装は楽だと思うけど)。
死滅へさらに加速する (スコア:0, 荒らし)
肥大化恐竜化で死滅へさらに加速するFirefox。
ググるの支援も打ち切られて狂暴度はさらにアップ。
一体今はバージョンいくつ？42000.10.12？
そろそろネスケと同じ末路を辿るのが見えて、
何とも皮肉が効いている。
Re:死滅へさらに加速する (スコア:1)
Firefox 8.0.1のxul.dll 15,419KB
Chrome 16.0.912.63のchrome.dll 28,128KB
ごく簡単に確認できる基本的な事実くらいは調べてから発言したほうが恥をかかずに済みますよ。
# で、Chromeはどうやって倍近い大きさのバイナリをビルドしてるんだろう。
Re:死滅へさらに加速する (スコア:2, 参考になる)
Chromeは64bit Windowsでビルドしている [pcworld.com]そうです。
Re: (スコア:0)
＞Chromeはどうやって
専用の特殊サーバ数百台で分散ビルドしている、とかかも知れない
Re: (スコア:0)
PGOって分散ビルドすると1プロセスあたりの使用メモリ量を減らせるようになってるんですか?
Re: (スコア:0)
いやいやいや、専用特殊サーバってのは、コンパイラやリンカはもちろん、OSもハードも
Googleの独自開発、というボケにそのツッコミは勘弁してください('A`)
Re: (スコア:0)
Re: (スコア:0)
でもChrome（Chromium）というかWebkitの方が肥大化という意味では先行しているの。
そろそろ名前変える時期かな (スコア:0)
ネスケ→Mozilla→Firebird→Firefoxとずっと使ってきたけど
肥大化したから名前変えて再出発の歴史だったような気がするから
Firefoxもそろそろそんな時期に来たんだろうか
つかFirefoxも4以降肥大化が加速してる感じだし
Re:そろそろ名前変える時期かな (スコア:1)
＞肥大化したから名前変えて再出発の歴史だったような気がするから
バイナリサイズやコードの肥大化が原因での名称変更はMozilla→Phoenixだけでしょう。その後は
Phonenix（BIOSメーカと衝突）→Firebird（データベース名称と衝突）→Firefox
という具合に、ほとんど商標の問題だと思います。
Re: (スコア:0)
Firebirdについては法的な問題ではなかったんだけど、異議申し立てに応じた感じでしたね。
そういいつつ、Firefoxもイギリスで衝突していて、合法的な解決をしたはずです。
64bit (スコア:0)
FirefoxもThunderbirdも64bit版を標準とするにはまだ早いんでしょうか
Re: (スコア:0)
そうすると16bitアプリケーションが動かなくなって業務が停止します（それは俺の責任じゃないからサボれて嬉しいな～）
Re:基本に立ち返ってダイエット (スコア:1)