Windows 8には128bit版が登場? 172
ストーリー by makeplex
IA128もまもなく登場しますかね 部門より
IA128もまもなく登場しますかね 部門より
あるAnonymous Coward 曰く、
マイクロソフトがWindows 8で128bit版を開発しているとの情報が明らかになり、本家/.で話題となっている。
この情報、マイクロソフトの開発者がビジネス特化SNSである「LinkedIn」にうっかり記述したことで人々の目に留まることとなったそうだ。現在このエントリは削除されているが、残されたキャッシュによると「(マイクロソフトの)R&Dで中~長期プロジェクトの戦略的事業計画に携わっている。プロジェクトにはWindows 8カーネル及びWindows 9事業計画における128bit互換アーキテクチャなどを含む。IntelやAMD、HP、IBMらを主なパートナーとして事業関係を築く」といった内容が記載されていたとのこと。
プロフィールには「high-security」なR&D部署で働いていると書かれているのだが、本人のhigh-security意識がいささか不十分だった模様です。
だから昔から言っておるようにだな (スコア:5, おもしろおかしい)
私が若返りを実行する予定の 2070年には 1024bit のファイルシステムが必要なんじゃよ。
それに対応するには CPU も 1024bit にするのが一番じゃ。
なぜ、そうちまちまと 2倍づつ増やそうとするかな。最初からどーんと 1024bit で統一してしまえば、自分達の代ではもう、インターフェース周りの互換性だの何だので苦労する必要は大幅に減るというのに。vfs層とか、仮想化層とか、いろいろな。
.
なに、1024bit ファイルシステムなんかあっても、保存するデータが無い?
今のファイルシステムは、NTFSも含めて、sparse file というものが作れる。つまり「歯抜け」状態になったファイルが作れるんじゃ。なので「全長」は 1Gbyte もあるが、スカスカなので1.44Mbyte のフロッピーディスクに収まるようなファイル、は今でも作れるのじゃ。そういう「スカスカ」なファイルは「スカスカ」であること自体に意味があるので、ファイルとしてのアドレス空間は大きくなくてはいかんのじゃ。
ところが、このようなファイルを mmap() でメモリに貼り付けようとすると、やはりメモリのアドレス空間自体、ファイルの「全長」分ぐらいはなくてはいかん。歯抜けになっているブロックは、物理メモリを割り振る必要は無いがな。なので、CPUもやはり 1024bit が必要なのじゃよ。
.....
# いかん、冗談なのかまじめな話なのか、判らなくなった…。
fjの教祖様
Re:だから昔から言っておるようにだな (スコア:1)
8Kbit CPU の Z80K
16Kbit CPU の 8086K
32Kbit CPU の 68M
とかはどうでしょう.
# 1024bit って...昔のメモリか?
Re:だから昔から言っておるようにだな (スコア:2, おもしろおかしい)
> # 1024bit って...昔のメモリか?
1024bit CPU で 8bit CPU のエミュレーター作るとか面白そうですね。
プログラムすべてがレジスタに乗っかってる状態なんてのが結構ありそうで、
ちょっとアレゲかも。ははは、見ろ、レジスタがバンクメモリのようだ。
Re:だから昔から言っておるようにだな (スコア:2, 興味深い)
#BGAだけど
Re:だから昔から言っておるようにだな (スコア:1)
きっとシリアル通信なんですよ(?)
Re:だから昔から言っておるようにだな (スコア:2)
レジスタだけ1024bitでバスは64bitという方法も。
# それなんて地雷GPU?・・・いや386SXか
Re:だから昔から言っておるようにだな (スコア:1)
Re:だから昔から言っておるようにだな (スコア:1)
いえ、ハリセンボン [wikipedia.org] です。
# ピンが放熱フィンを兼ねてるのさ…きっと。
まぁ、まじめにつくるとしたらシリアルだろう。それも光多重通信。
fjの教祖様
呼ばれたような気がしたが (スコア:5, おもしろおかしい)
Re:呼ばれたような気がしたが (スコア:3, おもしろおかしい)
32bitなせんぱい、これからは私の時代です! ごゆっくりお休みください!
#とか書こうとアカウントとったらACに先越された
##いらない子っていわないで>のびー
Re:呼ばれたような気がしたが (スコア:2, おもしろおかしい)
Re:呼ばれたような気がしたが (スコア:2)
ここを見ると分かるのですが、既に移行済みなのです
128bitかぁ…ふう (いや、あれは128ビットじゃない) (スコア:4, おもしろおかしい)
/* 128ビット記念 */
long long long int foo = -1;
printf("0x%xlll\n",foo); // 0xffffffffffffffffffffffffffffffff
/* 長ぇー */
Re:128bitかぁ…ふう (いや、あれは128ビットじゃない) (スコア:1, 興味深い)
http://www.kmonos.net/alang/d/2.0/type.html [kmonos.net]
Re:128bitかぁ…ふう (いや、あれは128ビットじゃない) (スコア:1)
Cだとstdint.hにint128_tが定義されたりするんでしょうか。
# Javaはどうするつもりだろう?
言ってないことに反論するなよ
Re:128bitかぁ…ふう (いや、あれは128ビットじゃない) (スコア:2, おもしろおかしい)
インテルから具体的な話がある可能性 (スコア:4, すばらしい洞察)
思うのですが、128bitCPUは結構早く出てくるのではないでしょうか。
現在の64bitはAMD64が主流ですが。
インテルが頑としてこの名前を使いたがらない、COREアーキテクチャの64bit対応が実にお座なりだったコト等から考えるに、インテルは64bitの主導権を取られたことを「最大の恥部」と捉えているのではないでしょうか。
インテルがこの「恥部」を抹消する為に
「128bitCPUを作って(初めは)安くでバラまいて、さっさと普及させればいいんじゃね?」
と考えていても、不自然ではないと思います。
そんな背景があるとしたら、128bitカーネル開発に乗り出していても納得出来るのですが。
どんなもんでしょうね?
Re:インテルから具体的な話がある可能性 (スコア:3, 興味深い)
ビジネス的にはそうかもしれませんけど、ユーザ側にメリットがないとなかなか売れませんよね。64bitにはできなくて128bitだとできることってなんでしょうね? アドレス幅も不足しているわけではないし。そんなにたくさん命令セットもいらないような……
SPARCが早い時期から64bit CPUを実用していましたけど、ユーザの目からみると全く目立たなかったですしね……
人生は七転び八起き、一日は早寝早起き
Re:インテルから具体的な話がある可能性 (スコア:2)
>SPARCが早い時期から64bit CPUを実用していましたけど、ユーザの目からみると全く目立たなかったですしね……
今は亡きAlphaの立場は?
Re:インテルから具体的な話がある可能性 (スコア:2)
そうですかね。今持っているのが64bitで、出来ることも値段も同じだったら今のものを使い続けると思います。
現に64bit Windowsを使っているのは4GB以上のメモリを使いたい人が中心で、あとは一部の新し物好き個人ユーザだと思います。32bit Windowsを使い続けている人が多いのと同じ状況になるのではないですか? サードパーティにとっても128bitドライバを開発する負担が増えるわけですし。
人生は七転び八起き、一日は早寝早起き
Re:インテルから具体的な話がある可能性 (スコア:1)
たとえCPUの値段が同じでも、バス幅が倍増したCPUを取り付けられるマザーボードを
同じ値段で作るのは難しいと思う。
#ソケットのピン数と基板の層数等を増やして値段を上げない方法は在るんだろうか?
Re:インテルから具体的な話がある可能性 (スコア:1, すばらしい洞察)
> 個人が使うようなアプリケーションで128bitのメモリ空間(≠実装メモリ量)を必要とするものなんて考えられない
初代PC-9801の頃には「640KBものメモリを何に使うのかわからない」とか、
80386が出た頃には「(80286の上限を超える)16MB以上なんて絶対使わない」とか、
ちょっと前だと「4GBのメモリ空間なんて絶対埋まらない」とか考えられていたわけだから、
そのうち「昔の人はなんで128ビットのメモリ空間で足りるなんて思ってたんだろう?」とか
思われてしまうのではないかと。
Re:インテルから具体的な話がある可能性 (スコア:3, 参考になる)
「仮想86モードを使ったソフトウェアEMSドライバ」の出現によって、286にはどうやっても勝てない386の優位性が生まれて、それによって286は駆逐された感じでしたね。
当時はDOSな8086用プログラムが主流で、286も386も高速な8086としてしか使われておらず、
8086なプログラムを動かす分には同クロックで比べると386より286の方がちょっぴり速かったんだけど、せいぜい数パーセントの差。
ところが、Cバスに挿すようなハードウェアEMSメモリと、386プロテクトメモリを使ったソフトウェアEMSでは、メモリアクセスに数倍の速度差があるという…
Re:インテルから具体的な話がある可能性 (スコア:2, 参考になる)
XMSとEMSを混同されてませんか?
XMSは、80286/386を前提としたプロテクトメモリ活用方法であり、
1MB超の8086のバグ的仕様でアクセス(HMA)したり、
ドライバのAPIを経由して必要に応じてブロック転送(EMB)したり
することで、8086モードでも1MB超のメモリ空間の恩恵を得られるようにします。
EMSとは「8086モードでアクセスできる1MBのメモリ空間」内に窓(通常、16KB×4ページ)を用意し、
そこを通すことで、8086アーキテクチャで1MB超のメモリ空間を提供する技術です。
EMS自体は、8086アーキテクチャベースで、その「1MB超のメモリ」がどこにあるかは規定されてません。
で、その実現方法として、上述のXMSのように、ドライバが1MB超と1MB以内のメモリ間でブロック転送をするという「ソフトウェアEMS」なんてのもありましたが、速度的にはページ切替のたびにメモリコピーが発生するのでとんでもなく遅くなりました。
それと、1MB下のメモリ空間中の「窓」として、メインメモリを消費する、というデメリットもありました。後述のハードウェアEMSや仮想86ソフトウェアEMSでは、メモリマップ上の未使用部分にEMS用の窓を割り当てますので、メインメモリの640KBはそのまま使えます。
ハードウェアEMSは、汎用拡張スロットに配置したハードウェアで直接「窓」を提供するもの。メモリマップ上にはメモリはには存在せず、バンク切替の影に隠れてます。
拡張スロットの遅さから、メモリアクセスが内蔵メモリにくらべ格段に遅いですが、それでも、ソフトウェアEMSよりは、転送が発生しない分高速です。
最後に出てきた「仮想86モードソフトウェアEMS」ですが、、
80386のプロテクトモード下の仮想86モードでは、386プロテクトモードのMMU機能を有効にしたまま8086として動作するので、MMUを使って1MB超の「プロテクトメモリ」を8086からアクセスできるEMSの窓に直接配置することができました。
これが仮想86モードによるプロテクトメモリを利用したソフトウェアEMS。内蔵の高速なメモリが使えますし、オーバーヘッドもほとんどありません。
この方法は、仮想86モードもMMUも無い80286では、そもそも実現不可能です。
速度を比較すると
386の仮想86モードによるソフトウェアEMS >> Cバスなどの遅い拡張スロットに実装されたハードウェアEMS >> ブロック転送方式のソフトウェアEMS
って感じでした。
Re:インテルから具体的な話がある可能性 (スコア:1)
用途 (スコア:3, 参考になる)
これまで通りレジスタに収まる範囲でメモリマップを管理するとすると、
32bit:2^32 = 4GiB
64bit:2^64 = 172億GiB
128bit: 2^128 = 281兆YiB (=31穣6912杼6500垓5705京GiB)
のメモリが積める、という計算であってますでしょうか?
あってない悪寒がするけど、とりあえずあっていると仮定して。
http://www.johotsusintokei.soumu.go.jp/field/tsuushinsangyou02.html [soumu.go.jp]
によると、JPドメインに載っているコンテンツの量が13,609GBだそうなので、128bitCPUのマシンは、インターネットの全てのコンテンツを実メモリに載せて処理するくらいのことができるのですね。
Re:用途 (スコア:3, 参考になる)
19bit 1982年 320KB FD 5'2D
21bit 1982年 1.2MB(メガ) FD 8'2D
21bit 1984年 1.2MB FD 2HD
21bit 1989年頃 2MB メインメモリ
23bit 1998年 8MB メモリースティック
24bit 1995年頃 16MB メインメモリ
25bit 1984年 20MB HDD
27bit 2000年 64MB SDメモリーカード
28bit 2003年 256MB メモリースティックPro
30bit 1982年 CD-DA
30bit 1988年 640MB CD-ROM
31bit 2004年 2GB(ギガ) SDメモリーカード
32bit 2006年 4GB SDHC
32bit 2009年頃 4GB メインメモリ?
33bit 1999年頃 主流HDD?
34bit 1996年 9.4GB DVD 2層
35bit 2008年 32GB コンパクトフラッシュ
35bit 2008年 32GB SDHC
36bit 1999年 36GB HDD
36bit 2006年 50GB Blu-ray 2層
37bit 2001年 100GB HDD
39bit 2009年 300GB 次世代Blu-ray 10層
39bit 2007年 320GB 2.5型HDD
40bit 2007年 1TB(テラ) HDD
41bit 2009年 2TB(テラ) HDD
50bit 1PB(ペタ)
64bit 16EB(エクサ)
70bit 1ZB(ゼタ)
80bit 1YB(ヨタ)
関係ないですが外部記憶の簡単な一覧を作ってみました。
128bitとは言っても128bitまるまる必要なわけではなく64bit以上なんだと考えるとそんなに遠くでもなさそうな気がしたりしなかったり?
あと30年でエクサやゼタまで到達できるのか?
Re:用途 (スコア:2)
>128bitとは言っても128bitまるまる必要なわけではなく64bit以上なんだと考えるとそんなに遠くでもなさそうな気がしたりしなかったり?
64bit = 172億GiBのメモリの用途が汎用的に必要になればいいわけですよね(いいのか!?)
現状のハードディスクとかフラッシュはセクタに分けて管理していますが、これをやめて全部リニアなアドレスで管理するようになると仮定して。
HDDの容量は、50年で5000万倍になったのだそうです。
http://www.itmedia.co.jp/news/articles/0604/12/news088.html [itmedia.co.jp]
ということは大体1年で1.4倍になるので。
2006年に500GBだったHDDの記憶容量が172億GiBになるのは、大体2060年頃、と出ましたけど、どんなものでしょう?
SSEだけで考えてみる (スコア:2, 興味深い)
前々から思っていたのだけど。
SSE内で完結する処理って、いちおう128ビットコンピューティングではないのでしょうか?
4つのOS (スコア:2, おもしろおかしい)
現在私のサーバー機はXenServerでXP Pro 32ビット版が4つ同時に動いています。
私はすでに128ビットな環境です。
Re:4つのOS (スコア:1)
否
それは34ビットな環境だと思う。
対象となるCPUは? (スコア:1)
# GPU なら 128bit 以上のを聞いたよう...
ネタだネタ(Re:対象となるCPUは?) (スコア:3, 興味深い)
だいたい、驚異的に要件やら物理的な実装がすすんでいるけど、
4->8->16-32->64 と世代交代の間隔は伸びてるんだから、まだ先だ。
なんやかやで、32bit時代は20年ちかくあったじゃないか。
あと、128bitが必要になる頃には、まったくパラダイムの異なる
コンピュータになっていて欲しいなぁ。
Re:対象となるCPUは? (スコア:2, 興味深い)
確か、Crusoe のVLIWでできたコアは 128bit だ、と言ってなかったっけか??
# 結局、native モードを公開してもらえなかったので、本当かどうかは判りませんが。
fjの教祖様
Re:対象となるCPUは? (スコア:1)
32bit x 4core ってオチじゃないだろうな?
Re:対象となるCPUは? (スコア:1)
アキュムレータは、128bitだけど外部バスは32bitのx86-128sxなんてCPUが・・・
出たらイヤだなあ(^^;
♪潔くカッコよく生きてゆこう
Re:対象となるCPUは? (スコア:2)
64ビットプロセッサ上のC言語のデータモデルには
などがあり、sizeof(int)だけを見ても分かりません。
Snow LeopardはLP64を採用しているので、gcc -arch x86_64でコンパイルするとsizeof(int)は32になります。WindowsはLLP64。
128ビットプロセッサ時代にはさらにややこしくなるんでしょう。
Re:対象となるCPUは? (スコア:1)
ファティマが128bitだったと思うが (スコア:1, 参考になる)
ファティマの脳味噌が出現予定とは・・・。
しかもなんだって? Windowsが載るんだって?
なんつーか、すごくガンダムハンマー的だよな。
そんな未来なもんに、よりによってそんな古いものを・・・。
なるほど! (スコア:1)
マニアな人が買って、パッケージを飾って置く物なんですね
------------
惑星ケイロンまであと何マイル?
Re:対象となるCPUは? (スコア:5, おもしろおかしい)
Re:対象となるCPUは? (スコア:2)
Coreが4つあると、32x4だと128bitクラスね。
で、HTがあったりすると、256bitとかね。
Re:対象となるCPUは? (スコア:1)
Z80 を 16。。。(略)
マクロの基本は検索置換(by y.mikome)
Re:メインフレームでは珍しくない (スコア:4, 参考になる)
Re:メインフレームでは珍しくない (スコア:2, 興味深い)
notice : I ignore an anonymous contribution.
Re:メインフレームでは珍しくない (スコア:2, 参考になる)
投稿の元ネタを別のとこで日本語化して紹介していますが、
「Windows 8およびWindows 9向けのIA-128のIA-64命令との後方バイナリ互換」 [itmedia.co.jp]なので、
Itanium、Itanium 2 に続く、大型サーバーやメインフレーム向けのIntel次期CPU向けWindowsの話で、
パソコン向けのWindowsの話ではないです。
Re:メインフレームでは珍しくない (スコア:1)
-- LightSpeed-J
Re:メインフレームでは珍しくない (スコア:1)
要するに128bitアドレスを持つストレージを前提として, 単一レベル記憶 [wikipedia.org]を実現しようとすれば, 自然と128bitアドレス空間が必要になるって話ですね.
実際のところローカルなアドレス空間としては64bitで十分かとも思うのですが, ネットワーク上での識別とか各種アトリビュートビットを付加したいとか考え出すと128bitぐらいは欲しくなってきます.
Re: CPUが128bitになるならFPUも128bitに (スコア:2)
# で、桁落ちとか全く考えない輩が急増しそうな気が。
Re:広がるズレ (スコア:3, おもしろおかしい)
全然問題ない。バージョン5.0なんて2000だったじゃないですか。
言ってないことに反論するなよ