アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
初めての体験 (スコア:2, すばらしい洞察)
32bitで出来ることしか自分には出来ないです、、
Re:初めての体験 (スコア:3, すばらしい洞察)
飛び込む資格があるのなら、その64ビットがもたらしてくれる先進性を
出来る限り味わうべきだろう、たとえそれがつかの間の幸福であっても。
違うかい?
確かに、本格的にソフトウェア側が対応するまでは、
まだまだ時間があるだろう。80386が発表された頃だって、
そのパ
Re:初めての体験 (スコア:0)
だからこそLinuxが生まれたとも言えるわけですが……
さて、AMD64(x86-64bit extented system)のために新しいソフトウェア潮流は生まれるのでしょうか。
Re:初めての体験 (スコア:1)
結構流行ってますよね。ドでかい容量のHDDを積んで、アニメなんか取り込んだりして。
あのテの巨大なデータを64Bitのポインタでビシバシ扱えるというのは
利点じゃないでしょうか。
メモリアクセスに64Bitのポインタがあれば、展開したデータが
軽く4GBを超えていても、無理に圧縮して32Bitでポイントできる範囲に
納める必要などありませんし。
16ビット機が出た頃、8ビットマシンと16ビットマシンを比較して、
16ビット機は倍ぐらい難解で操作が難しいかというと、そうでもなかったはずです。
それより、大き
Re:初めての体験 (スコア:1)
> 結構流行ってますよね。ドでかい容量のHDDを積んで、アニメなんか取り込んだりして。
> あのテの巨大なデータを64Bitのポインタでビシバシ扱えるというのは
> 利点じゃないでしょうか。
HDTVの解像度1920*1080ドットの動画で考えてみましょうか。
- 1ドットを表現するのに、RGBで3バイト使う。
- 1フレーム1920*1080ドットの圧縮処理のために、前後も含めて3フレーム分の情報を使う。
と仮定すると、1920*1080*3*3=18662400バイト(約17.8MB)。圧縮アルゴリズムの中でどれだけのメモリーを要求されるのかはわかりませんが、おそらく圧縮前のフレーム情報と合わせても4GBも要らないのではないでしょうか。
余ったメモリー一杯までフレームを先読みすることで、ディスクアクセスを減らして速度を稼ぐという手もありますが、そうするにしても、重要なのは搭載している物理メモリー量であって、64bit化による仮想メモリー空間の拡大はあまり貢献しないように感じられます。
ということで、
> 今回はポインタがでかくなって大きなデータが扱えるようになるぐらいで、
> ドラスティック(抜本的)な変化は見られないのではないかと思います。
動画圧縮に関しても、このご意見に同意します。
Re:初めての体験 (スコア:0)
またアセンブリ言語の経験がある方はわかると思いますが、一度メモリにアクセスする度にアドレス決めたりで数ステップ余分に処理を食います。さらにメモリとCPUの間にあるバスのクロックはご存知の通りCPUの動作クロックよりもかなり低い
Re:初めての体験 (スコア:1)
フツーのアクセスなら、動画(画像)なら通常RGBA=8:8:8:8の32bitでアクセスするから64bitは生きてこない。
同時に2dot分packed演算すれば64bitアクセスの意味が出るけど、packed演算ならMMXのほうがよりよい。
処理するデータが64bitなら、今まで32bitx2回(乗除算等もっと増える場合もある)で処理してたのが1回ですむから速くなるけど
そういう処理はあまり多くない。少なくとも動画圧縮・伸張に関しては変わらんと思う。
Re:初めての体験 (スコア:0)
# データバスはPentium辺りからすでに64bit以上だし
メモリコピーなんかはほとんどキャッシュで隠蔽されてしまうので
64bitにして目に見えて速くなることはないでしょう。
むしろポインタサイズが64b