アカウント名:
パスワード:
・足りないのは物理メモリではなく仮想アドレス空間です。ラージページで物理メモリを節約できても関係ありません。・足りないのは実行時の(firefox.exeの)メモリではなくビルド時の(link.exeの)メモリです。改修できるのはMicrosoftだけです。
旧版Windowsでの動作を捨てて、最新のVisualStudioを使うと問題は生じない。だから、新機能は新OSでしか提供されないのさ。
DLLとして分かれている部分が多いから問題となってないとかですかね
>「64 ビット版 Windows でビルドする」などいくつかの解決策が提案されている。
この提案はWindowsにもそのまま適用できそうだけど。あと、Microsoftの製品はdllの集合体みたいなイメージがある。
あ、ラージページでカーネルがページテーブルに予約しているアドレス空間も節約できるかもしれませんが、足りないのはユーザー空間なのでどのみち関係ありません。
え?MSなら改修できるの?
MSがlink.exeでAWEを使うとか、メモリが足りなくなったら一時ファイルにスワップしてビルドを続行するとかの改修をlink.exeに行なってくれたらビルドできるようになるかもしれない。それよりも、早く64bit版のlink.exeでまともにPGOビルドできるようにしてくれって感じだが。
そういうやり方で3GB以上のメモリ空間を使えるようにしたとして、最適ビルドに何日かかるんだよ。
Windows7/2008R2以降、ほとんど売れているのは64ビット版のWindowsなんだから、そこまでやるか?俺だったらやらない。
OSが64bitになっててもpluginが32bitのままってのが多いからねぇ。IEも標準は32bitだし。
でもjavaとflashは64bit対応したし、そろそろ軸足を64bitに動かすのはありでしょうね。
ただ、32bit環境を切り捨てるにはまだ早すぎるでしょ。
だから#2067279 [srad.jp]を声出して10回読み直せ。ビルドの時に64bit環境が必要になるだけであって、ビルドされたものを使うだけのユーザーには関係ないし、プラグイン云々も関係ない。
64bit版firefoxのplugin-containerにnspluginwrapperをインプリメント…とか。
まず>32 ビット版 Windows は最大 3 GB までしかメモリを利用できないがここも関係してくるが32bit版Windowsにおいて1プロセスで使えるメモリは2GBまでに制限されている。だからこの部分を取り外せばもしかしたらビルドできるのでは?
> 32bit版Windowsにおいて1プロセスで使えるメモリは2GBまでに制限されている。そんな制限はない。32bitなんだから、1プロセスで使えるメモリは4GB。
通常はこの4GBを、システム2GB、アプリケーション2GBで使用する。ただしWindowsの起動時オプションで/3GBを指定すると、これをシステム1GB、アプリケーション3GBに変更できる。元コメの「32bit版Windowsは最大3GB」というのはこのことを言っている。
さらに言うと、Memory Limits for Windows Releases [microsoft.com]の“User-mode virtual address space for each 32-bit process”の欄に書いてあるのですが、64ビットWindowsで32ビットアプリを動かすと(3GBからさらに増えて)4GB使えます。これがストーリー本文に書いてある「64 ビット版 Windows でビルドする」という解決策の言っている意味となります。
なんでもマイクロソフトのせいとかギャグですか!改修できるのはインテルじゃないの?改修してできたのがx64アーキテクチャじゃないの?
Linuxは32ビットでも3GBの壁突破できたはず。例えばUbuntuはPAE有効版あります。
#コレでFireFoxのコンパイルできるのかどうかは知らない。
いちおう、PAEを有効にしてAWEを使うことで4GB越えのメモリを使うこともできるようですよ。話に聞いただけで使ったことがないので詳細分かりませんが、16bit時代のオーバーレイやEMSのようなもんでしょうか。
まぁ、そこまでして32bit版link.exeを改修しないでしょ。
x64 WindowsでWOW64環境であれば、殆ど4GBを使えます。(システムDLLの大半がラッパーDLLなので)
しかし、x64 link.exe でPGO出来るようにするのが優先でしょう。その前に、1モジュールでかすぎなんだよという突っ込みに賛成。
link.exeをIntelが作っているとは知りませんでした。まともな64bitのlink.exeがないのも、AWEを使ったりメモリがなくなるとファイルにスワップする等して何とか続行したりしないでInternal Errorを吐いてlink.exeがコケるのもIntelのせいだったんですね。
改修してできたのがx64アーキテクチャじゃないの?
AMDェ……。
VCのlink.exe作ったのはMSで、x64アーキテクチャ作ったのはAMDな(IntelはIA64作ったけどコケてAMDのx64に乗り換えた)。ICCのlink.exeの問題だったらIntelの領分だけど、VCの問題はMSの領分っしょ。そもそも32bit版link.exeの問題だから、x64は全く無関係だし。
>改修できるのはMicrosoftだけです。今(前から?)の /.J の状態を如実に表しているね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
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)
天下のMS様だよ?
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: (スコア:0)
だから#2067279 [srad.jp]を声出して10回読み直せ。
ビルドの時に64bit環境が必要になるだけであって、ビルドされたものを使うだけのユーザーには関係ないし、プラグイン云々も関係ない。
Re: (スコア:0)
64bit版firefoxのplugin-containerにnspluginwrapperをインプリメント…とか。
Re: (スコア:0)
まず
>32 ビット版 Windows は最大 3 GB までしかメモリを利用できないが
ここも関係してくるが32bit版Windowsにおいて1プロセスで使えるメモリは2GBまでに制限されている。
だからこの部分を取り外せばもしかしたらビルドできるのでは?
Re: (スコア:0)
> 32bit版Windowsにおいて1プロセスで使えるメモリは2GBまでに制限されている。
そんな制限はない。32bitなんだから、1プロセスで使えるメモリは4GB。
通常はこの4GBを、システム2GB、アプリケーション2GBで使用する。
ただしWindowsの起動時オプションで/3GBを指定すると、これをシステム1GB、アプリケーション3GBに変更できる。
元コメの「32bit版Windowsは最大3GB」というのはこのことを言っている。
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)
いちおう、PAEを有効にしてAWEを使うことで4GB越えのメモリを使うこともできるようですよ。
話に聞いただけで使ったことがないので詳細分かりませんが、16bit時代のオーバーレイやEMSのようなもんでしょうか。
まぁ、そこまでして32bit版link.exeを改修しないでしょ。
Re: (スコア:0)
x64 WindowsでWOW64環境であれば、殆ど4GBを使えます。
(システムDLLの大半がラッパーDLLなので)
しかし、x64 link.exe でPGO出来るようにするのが優先でしょう。
その前に、1モジュールでかすぎなんだよという突っ込みに賛成。
Re: (スコア:0)
link.exeをIntelが作っているとは知りませんでした。
まともな64bitのlink.exeがないのも、AWEを使ったりメモリがなくなるとファイルにスワップする等して何とか続行したりしないでInternal Errorを吐いてlink.exeがコケるのもIntelのせいだったんですね。
Re: (スコア:0)
改修してできたのがx64アーキテクチャじゃないの?
AMDェ……。
Re: (スコア:0)
VCのlink.exe作ったのはMSで、x64アーキテクチャ作ったのはAMDな(IntelはIA64作ったけどコケてAMDのx64に乗り換えた)。
ICCのlink.exeの問題だったらIntelの領分だけど、VCの問題はMSの領分っしょ。
そもそも32bit版link.exeの問題だから、x64は全く無関係だし。
Re: (スコア:0)
>改修できるのはMicrosoftだけです。
今(前から?)の /.J の状態を如実に表しているね。