アカウント名:
パスワード:
メモリーたくさん使えるくらいしか思いつかない。
OSとしてのメリットはCPUの命令とかキャッシュとか同時実行とかいろいろあるけどアプリとして64bitのメリットがあんまり思いつかない。
# 動画とかレンダリングをゴリゴリするなら別だけどどうなんだろう
とりあえず、レジスタがたくさん使える
他に、x86-64特有で地味だけど意外と強力な機能として、RIP相対のアドレシングができるようになったというのも大きいです。そんなもんの何がうれしいかというと、DLLだの.soだのといった position independent code では、何をするにつけても現在のRIP(32ビットならEIP)からの相対アドレスという形になるんですが、これがかなりシンプルになって効率も上がるわけで。
> DLLだの.soだのといった言わんとすることはわかるけど、DLLはPICではなく、ロード時にリロケーションします。別アドレスにロードするとリロケーション部分が共有できなくなるので極力同じアドレスにロードするようになっていて、そのため攻撃しやすくなっていました。
言い換えるとlinux gccでsoを作るとき-fPIC -DPICを指定しますがWindows DLLでは指定しません。
いろいろフレームワークがあってなんちゃらDLLとか昔よりたくさんロードしないといかんのですよ。アドレス空間圧迫して、せっかくメモリがあってもアプリ用にマップできなくなる。DLLはどうせ誰かがロードするのでメモリ自体は大して食わないだろうけど、空間はプロセスで平等に食われる。
アプリとしてというと微妙だけどグラフィック関係はアドレス空間たくさんあったほうがドライバやライブラリとしてもいろいろやりやすいよね
自分(Firefox)に関係ないDLLは、自分の論理アドレスを侵食してくることはないんじゃないの?
高速化のためにメチャクチャメモリ食う思想が正義のご時世に、使用可能なメモリを無尽蔵にすることを諦めるのはどう出るか今後もっとメモリが増設されて、ブラウザが4GBぐらい食うのが当たり前の時代になったときFirefoxは終わる
その頃にはブラウザプラグインが絶滅してるから問題なく64bit移行できるのでは
むしろブラウザプラグイン不要な世の中になってくれてたら嬉しいなあ。
> ブラウザが4GBぐらい食うのが当たり前の時代になったときFirefoxは終わるもう既にそういう時代になってるとおもいますが。
で、同時に「ブラウザが200MBもメモリ食ってる! バグだ!」と騒ぐ人がいたりメモリを500MB使っているというだけの理由でNortonがブロックしたりするんだからまったくわけがわからないよ。
Windowsはおちゃらけクイックソート保護機能(?)によって、32bit環境では原則2GBで死にますよ。実質だと1.6~1.8GB。Windowsの起動オプションで許可すれば3GBくらいまではアプリで使えるけど、アプリ側で2GB超サポートフラグをONにしないとこの機能は動きません。# クイックソートの適当実装ではメモリアドレスを加算して2で割るとかいうアホな実装が存在してて、最上位ビットが1な上位2GBのメモリを使うと爆死するって現象が存在しててそれ回避+メモリ管理の簡略化(上位2GBを共有メモリ&システム領域に固定して仮想メモリ機能の範囲外とする的な9x時代の小技とか云
Flashと、高速PDFviewer(Adobe製は重くて…)と、WMP/Silverlight ぐらいしかプラグインって要らないのではと。特にJava、お前は入れてやらねー。
JREはアップデータがアップデート失敗するようになったので一旦アンインストールしましたが、何ら問題なくPC使ってます(笑)
Silverlightなんて勘弁してください。FlashとAdobeで手一杯です。
実はそう思う。それに「動く」ってだけでメモリ問題は他のソフトにおっ被せ…いや面倒見て貰ってしまえば、ほとんど32bitの構成のままでさえ、利点は有ると思うんのだが。プラグインが対応しないのなんては、対応するまで放置で良いと思うし。
いまのFireFoxなんて、テキトーな対応ですら無茶苦茶効果がありそうなのにもったいない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
64bit版ならではの機能とか (スコア:2)
メモリーたくさん使えるくらいしか思いつかない。
OSとしてのメリットはCPUの命令とかキャッシュとか同時実行とかいろいろあるけど
アプリとして64bitのメリットがあんまり思いつかない。
# 動画とかレンダリングをゴリゴリするなら別だけどどうなんだろう
Re:64bit版ならではの機能とか (スコア:2)
とりあえず、レジスタがたくさん使える
Re: (スコア:0)
他に、x86-64特有で地味だけど意外と強力な機能として、RIP相対のアドレシングができるようになったというのも大きいです。
そんなもんの何がうれしいかというと、DLLだの.soだのといった position independent code では、何をするにつけても現在のRIP(32ビットならEIP)からの相対アドレスという形になるんですが、これがかなりシンプルになって効率も上がるわけで。
Re:64bit版ならではの機能とか (スコア:1)
> DLLだの.soだのといった
言わんとすることはわかるけど、DLLはPICではなく、ロード時にリロケーションします。
別アドレスにロードするとリロケーション部分が共有できなくなるので極力同じアドレスにロードするようになっていて、そのため攻撃しやすくなっていました。
言い換えるとlinux gccでsoを作るとき-fPIC -DPICを指定しますがWindows DLLでは指定しません。
Re:64bit版ならではの機能とか (スコア:2, 興味深い)
いろいろフレームワークがあってなんちゃらDLLとか昔よりたくさんロードしないといかんのですよ。
アドレス空間圧迫して、せっかくメモリがあってもアプリ用にマップできなくなる。
DLLはどうせ誰かがロードするのでメモリ自体は大して食わないだろうけど、空間はプロセスで平等に食われる。
アプリとしてというと微妙だけどグラフィック関係はアドレス空間たくさんあったほうが
ドライバやライブラリとしてもいろいろやりやすいよね
Re: (スコア:0)
自分(Firefox)に関係ないDLLは、自分の論理アドレスを侵食してくることはないんじゃないの?
Re: (スコア:0)
高速化のためにメチャクチャメモリ食う思想が正義のご時世に、使用可能なメモリを無尽蔵にすることを諦めるのはどう出るか
今後もっとメモリが増設されて、ブラウザが4GBぐらい食うのが当たり前の時代になったときFirefoxは終わる
Re:64bit版ならではの機能とか (スコア:1)
その頃にはブラウザプラグインが絶滅してるから問題なく64bit移行できるのでは
Re: (スコア:0)
むしろブラウザプラグイン不要な世の中になってくれてたら嬉しいなあ。
Re: (スコア:0)
> ブラウザが4GBぐらい食うのが当たり前の時代になったときFirefoxは終わる
もう既にそういう時代になってるとおもいますが。
Re: (スコア:0)
で、同時に「ブラウザが200MBもメモリ食ってる! バグだ!」と騒ぐ人がいたりメモリを500MB使っているというだけの理由でNortonがブロックしたりするんだからまったくわけがわからないよ。
Re: (スコア:0)
Windowsはおちゃらけクイックソート保護機能(?)によって、32bit環境では原則2GBで死にますよ。実質だと1.6~1.8GB。
Windowsの起動オプションで許可すれば3GBくらいまではアプリで使えるけど、アプリ側で2GB超サポートフラグをONにしないとこの機能は動きません。
# クイックソートの適当実装ではメモリアドレスを加算して2で割るとかいうアホな実装が存在してて、最上位ビットが1な上位2GBのメモリを使うと爆死するって現象が存在しててそれ回避+メモリ管理の簡略化(上位2GBを共有メモリ&システム領域に固定して仮想メモリ機能の範囲外とする的な9x時代の小技とか云
もうプラグインは数本しかいらない (スコア:0)
Flashと、高速PDFviewer(Adobe製は重くて…)と、WMP/Silverlight ぐらいしかプラグインって要らないのではと。
特にJava、お前は入れてやらねー。
Re: (スコア:0)
JREはアップデータがアップデート失敗するようになったので一旦アンインストールしましたが、
何ら問題なくPC使ってます(笑)
Silverlightなんて勘弁してください。FlashとAdobeで手一杯です。
Re: (スコア:0)
実はそう思う。
それに「動く」ってだけでメモリ問題は他のソフトにおっ被せ…いや面倒見て貰ってしまえば、
ほとんど32bitの構成のままでさえ、利点は有ると思うんのだが。
プラグインが対応しないのなんては、対応するまで放置で良いと思うし。
いまのFireFoxなんて、テキトーな対応ですら無茶苦茶効果がありそうなのにもったいない。