アカウント名:
パスワード:
>64bit化して早くなるのは64bit整数演算ぐらいだし
64bit化して速くなるのは, 最近の多くのOSでは実はファイル入出力だったりするんですけどね.
というのも主記憶をバッファとして有効に使うために, ファイルを仮想記憶空間上にマッピングしてページ単位でIOを行うってのが現在の主流です. ところがこのOSカーネルが行う処理は, 大きなファイルでも一括で扱える64bitと, 32bit空間毎に分割して取り扱わねばならないのとではオーバヘッドの量が大違いになります.
さらにユーザ空間のプログラムから見た場合, 32bitOSでは32bit空間を越えるファイルを含めて取り扱う時にread/writeシステムコールを使うとすれば, OSカーネルが一旦主記憶上にバッファリングした内容をユーザプログラムが用意したバッファにコピーするという二度手間になり性能が劣化します. mmapシステムコールを使っても最大32bit空間単位でこま切れにしないと取り扱えないので, やはりプログラムの複雑化とそれに伴うオーバヘッドは避けられません. このプログラム上の問題は, Macで良く使われるマルチメディア系において顕著です.
こうしたプログラム上の問題ってのは, たとえハードの方が対応したとしても尾を引く物なので(WindowsがPentiumProを活かせなかったのがその典型です), たとえ今現在のメモリ容量が2GBに満たないとしても, 先行して手を打っておくべきものでしょう. まして今回はCPUアーキテクチャが変わるというタイミングですから, 今後のソフトウェア資産の継続性という点からも, 少々の問題が有っても64bit化するべきじゃなかったんですかね.
# いや, もしかしたら今回はつなぎに徹した捨てラインナップなのかも
歴史的に見ると, 64KBセグメントを喜んで使っていたなんてConcurrent-CP/Mまんせーなんて言っているCP/M資産に縛られた組み込み屋さんぐらいなもんでしたよ. というか当時のx86セグメントってCP/M前提みたいなもんでしたから. コンパイラやリンカのsmallやらlargeなんぞのオプションに一喜一憂していたのは苦行以外のなにものでもなかったです.
むしろ8bitから16bitに移行した時点でせめて20bit程度はリニアに使えなければプログラミングに苦労することは明白になっていたわけで, それ故に386より前のインテルCPUクズ, リニアに24bit以上使える68kまんせー論がまかりとおっていたわけです.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
64bit化はしないのね (スコア:4, 興味深い)
せっかくこの時期だから最初から64bitで行けばよかったのではないかと思うのですが。
Mobile環境を優先した結果なのかな。魅力75%減。
Windows陣営がVistaから本格的に64bit化を推し進めてくれば、性能的には突き放されるように思います。
Re:64bit化はしないのね (スコア:0)
64bit化して早くなるのは64bit整数演算ぐらいだし. それにOS自体もそんな早いものでは無いので,「Macを使う」と言う文字通りの意義以外はありません.
Re:64bit化はしないのね (スコア:5, 参考になる)
>64bit化して早くなるのは64bit整数演算ぐらいだし
64bit化して速くなるのは, 最近の多くのOSでは実はファイル入出力だったりするんですけどね.
というのも主記憶をバッファとして有効に使うために, ファイルを仮想記憶空間上にマッピングしてページ単位でIOを行うってのが現在の主流です. ところがこのOSカーネルが行う処理は, 大きなファイルでも一括で扱える64bitと, 32bit空間毎に分割して取り扱わねばならないのとではオーバヘッドの量が大違いになります.
さらにユーザ空間のプログラムから見た場合, 32bitOSでは32bit空間を越えるファイルを含めて取り扱う時にread/writeシステムコールを使うとすれば, OSカーネルが一旦主記憶上にバッファリングした内容をユーザプログラムが用意したバッファにコピーするという二度手間になり性能が劣化します. mmapシステムコールを使っても最大32bit空間単位でこま切れにしないと取り扱えないので, やはりプログラムの複雑化とそれに伴うオーバヘッドは避けられません. このプログラム上の問題は, Macで良く使われるマルチメディア系において顕著です.
こうしたプログラム上の問題ってのは, たとえハードの方が対応したとしても尾を引く物なので(WindowsがPentiumProを活かせなかったのがその典型です), たとえ今現在のメモリ容量が2GBに満たないとしても, 先行して手を打っておくべきものでしょう. まして今回はCPUアーキテクチャが変わるというタイミングですから, 今後のソフトウェア資産の継続性という点からも, 少々の問題が有っても64bit化するべきじゃなかったんですかね.
# いや, もしかしたら今回はつなぎに徹した捨てラインナップなのかも
Re:64bit化はしないのね (スコア:1, 参考になる)
x86-64に限ればレジスタ数が増えるので、I/Oに限らず速くなるんですよね。
Re:64bit化はしないのね (スコア:0)
歴史を鑑みると64KBのセグメントをみんな喜んで使ってたわけで、そうゆう問題はMacの競争力には何も影響しない可能性が高いですね。
Re:64bit化はしないのね (スコア:2, 興味深い)
歴史的に見ると, 64KBセグメントを喜んで使っていたなんてConcurrent-CP/Mまんせーなんて言っているCP/M資産に縛られた組み込み屋さんぐらいなもんでしたよ. というか当時のx86セグメントってCP/M前提みたいなもんでしたから. コンパイラやリンカのsmallやらlargeなんぞのオプションに一喜一憂していたのは苦行以外のなにものでもなかったです.
むしろ8bitから16bitに移行した時点でせめて20bit程度はリニアに使えなければプログラミングに苦労することは明白になっていたわけで, それ故に386より前のインテルCPUクズ, リニアに24bit以上使える68kまんせー論がまかりとおっていたわけです.
Re:64bit化はしないのね (スコア:1)
Re:64bit化はしないのね (スコア:0)
でも68kを積んだMacがバカ売れしたわけじゃないですよね?
なんだかんだ言ってx86を喜んで使ってたわけでしょ。
世の中にはマゾが多いんですね〜
Re:64bit化はしないのね (スコア:0)
Macも32KBの制限あったりして大してかわんなかったでしょ。
Re:64bit化はしないのね (スコア:0)
32Kの制限がグローバル領域と相対ジャンプのどっちのことかわからないけど、ヒープが必ず64KB以下ってのは全然次元の違う制限だよね。
その32KB制限はどちらも後のコンパイラの機能向上で解決したんじゃなかったかな(少なくともCodeWarriorではラージモデルやFarデータが指定できる)。
Windows 3.1向けのPhotoshopを見て、386リニア空間を使えない状態でフォトレタッチという応用は無茶だと思ったな。
Re:64bit化はしないのね (スコア:0)
PowerBook G4で一番解消して欲しいことが僅か2GBのメモリ量制限だった。