アカウント名:
パスワード:
>64bit on 64bitよりは作りが素直
そうか?っていうか要出典。
OSの親子関係をいちいち(アキュムレータの)ビット数の多寡に割り当ててたら、むしろスケーラビリティが低くてたまらないんじゃないのか?
VxWareやVirtualBOXに代表されるネィティブバイナリの動く仮想化技術というのは、まさに
と言うか、全てのレジスタを動的に複数のOS環境に(見た目)同時に提供してるのですが…?それこそ、特権レジスタや一個しかない外部ハードウェアなどへのアクセスであってもHookして何もトラップされていないようにゲストOS側から見せてしまっている。で、流石にスケーラビリティの問題が深刻だったのか最近の汎用CPUでは仮想化支援機能(リンク先はx86アーキテクチャの場合)をハードウェアで持つようになって [wikipedia.org]きてる訳ですが。
128bit CPUが普通になってる世界というのは未だはっきりとは見えないですが、複数の仮想64bit OS実行環境を一つのMPU・一つの主記憶でこなす為にもの凄い冗長なレジスタ構成(ビット長だけではなくレジスタの数的にも)を持たせる事自体のコスト的なアドバンテージが産まれてきたらそうなるんじゃないですか?技術的な壁は非常に厚いでしょうが。
今は2^64バイト以上のDRAMを作るのも容易ではないしそれだけの主記憶があったとして、それを隅々まで活用出来るような高速な演算が必要とされる用途は限定されるけど、それが家庭などで普通に必要になった世界というのもありうるでしょうから…
>同じ大きさの箱のやりくりは小細工が要る
逆ザヤだと流石に色々面倒だが、同じなら別に困らんだろ。箱といってもアドレス幅そのものが箱になるわけではないんだから。
#むしろ同じでない事が招く面倒のほうが、大きい。
現実的に「同じ大きさの箱が厳しい」ことが多いのは、箱は箱でもメモリ「量」の都合だ。エミュなんて使うのはOS(子のほう)が目一杯進化した後であることが多い。(その後にその1ランク上のOSが出てきて、それを親として使う、というパターンが多いんで。)そうなると、子OSのほうは得てして既にアーキテクチャ目一杯のメモリ量を使ってるから、親が同アーキテクチャだとそれこそメモリ量の心配をする必要に迫られる。
32bit同士でもメモリ少量しか使わない子OSと目一杯搭載した親の組み合わせなら別に苦もなく動かせるよ。むしろ例えば同アーキテクチャだとエミュの効率があがることが多い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
対象となるCPUは? (スコア:1)
# GPU なら 128bit 以上のを聞いたよう...
ネタだネタ(Re:対象となるCPUは?) (スコア:3, 興味深い)
だいたい、驚異的に要件やら物理的な実装がすすんでいるけど、
4->8->16-32->64 と世代交代の間隔は伸びてるんだから、まだ先だ。
なんやかやで、32bit時代は20年ちかくあったじゃないか。
あと、128bitが必要になる頃には、まったくパラダイムの異なる
コンピュータになっていて欲しいなぁ。
Re:ネタだネタ(Re:対象となるCPUは?) (スコア:0)
128bitを自分で使うというのではなく、64bit版OSを複数動かす為のOSという。
その位の役割なら明日から売っても不思議じゃあないし、64bit on 64bitよりは作りが素直になる。
Re: (スコア:0)
>64bit on 64bitよりは作りが素直
そうか?
っていうか要出典。
OSの親子関係をいちいち(アキュムレータの)ビット数の多寡に割り当ててたら、
むしろスケーラビリティが低くてたまらないんじゃないのか?
あながちネタとも言えない(Re:ネタだネタ(Re:対象となるCPUは?) (スコア:1)
VxWareやVirtualBOXに代表されるネィティブバイナリの動く仮想化技術というのは、まさに
と言うか、全てのレジスタを動的に複数のOS環境に(見た目)同時に提供してるのですが…?
それこそ、特権レジスタや一個しかない外部ハードウェアなどへのアクセスであってもHookして何もトラップされていないようにゲストOS側から見せてしまっている。
で、流石にスケーラビリティの問題が深刻だったのか最近の汎用CPUでは仮想化支援機能(リンク先はx86アーキテクチャの場合)をハードウェアで持つようになって [wikipedia.org]きてる訳ですが。
128bit CPUが普通になってる世界というのは未だはっきりとは見えないですが、複数の仮想64bit OS実行環境を一つのMPU・一つの主記憶でこなす為にもの凄い冗長なレジスタ構成(ビット長だけではなくレジスタの数的にも)を持たせる事自体のコスト的なアドバンテージが産まれてきたらそうなるんじゃないですか?
技術的な壁は非常に厚いでしょうが。
今は2^64バイト以上のDRAMを作るのも容易ではないしそれだけの主記憶があったとして、それを隅々まで活用出来るような高速な演算が必要とされる用途は限定されるけど、それが家庭などで普通に必要になった世界というのもありうるでしょうから…
Re: (スコア:0)
大きな箱の中に小さな箱を並べるのは楽だが、同じ大きさの箱のやりくりは小細工が要るというだけの話だよ。
小細工のハードルの高低はあるにせよ、小細工なんぞ不要ならそれに越した事は無い。
特にベース部分には。
Re: (スコア:0)
>同じ大きさの箱のやりくりは小細工が要る
逆ザヤだと流石に色々面倒だが、同じなら別に困らんだろ。
箱といってもアドレス幅そのものが箱になるわけではないんだから。
#むしろ同じでない事が招く面倒のほうが、大きい。
現実的に「同じ大きさの箱が厳しい」ことが多いのは、箱は箱でもメモリ「量」の都合だ。
エミュなんて使うのはOS(子のほう)が目一杯進化した後であることが多い。
(その後にその1ランク上のOSが出てきて、それを親として使う、というパターンが多いんで。)
そうなると、子OSのほうは得てして既にアーキテクチャ目一杯のメモリ量を使ってるから、
親が同アーキテクチャだとそれこそメモリ量の心配をする必要に迫られる。
32bit同士でもメモリ少量しか使わない子OSと目一杯搭載した親の組み合わせなら別に苦もなく動かせるよ。
むしろ例えば同アーキテクチャだとエミュの効率があがることが多い。