by
Anonymous Coward
on 2006年01月12日 11時16分
(#863373)
> Macも32KBの制限あったりして大してかわんなかったでしょ。
32Kの制限がグローバル領域と相対ジャンプのどっちのことかわからないけど、ヒープが必ず64KB以下ってのは全然次元の違う制限だよね。 その32KB制限はどちらも後のコンパイラの機能向上で解決したんじゃなかったかな(少なくともCodeWarriorではラージモデルやFarデータが指定できる)。 Windows 3.1向けのPhotoshopを見て、386リニア空間を使えない状態でフォトレタッチという応用は無茶だと思ったな。
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空間を越えるファイル
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化はしないのね (スコア:0)
でも68kを積んだMacがバカ売れしたわけじゃないですよね?
なんだかんだ言ってx86を喜んで使ってたわけでしょ。
世の中にはマゾが多いんですね〜
Re:64bit化はしないのね (スコア:0)
Macも32KBの制限あったりして大してかわんなかったでしょ。
Re:64bit化はしないのね (スコア:0)
32Kの制限がグローバル領域と相対ジャンプのどっちのことかわからないけど、ヒープが必ず64KB以下ってのは全然次元の違う制限だよね。
その32KB制限はどちらも後のコンパイラの機能向上で解決したんじゃなかったかな(少なくともCodeWarriorではラージモデルやFarデータが指定できる)。
Windows 3.1向けのPhotoshopを見て、386リニア空間を使えない状態でフォトレタッチという応用は無茶だと思ったな。