HDD が進化し、より少ないスペースでより多くのスペースを提供する一方で、なぜ 32 ビットまたは 64 ビットに「こだわる」のでしょうか?
たとえば、128ビットプロセッサが存在できないのはなぜですか?
(これは私の宿題ではありません。私は、彼らが教えてくれる情報学以外のことに興味を持っている学生です)
8 に答える
5
32 ビットと 64 ビットの違いは天文学的であるため、実際には2 32 (10 億の 10 桁の数) と2 64 (1000 億の 20 桁の数 :-) の違いです。
今後数十年は64ビットで十分です。
于 2010-04-12T12:42:18.747 に答える
4
これの必要性はほとんどありません。いつそんなに大きな数を扱うのでしょうか? 64 ビットで使用できる現在のアドレス指定可能なメモリ空間は、少なくとも数年間はマシンが処理できる容量をはるかに超えています...そして、それを超えると、おそらくどのデスクトップがかなりの期間保持できる容量よりも多くなります.
はい、デスクトップのメモリは増え続けますが、現在の40 億倍ですか? それにはしばらく時間がかかります...確かに、現在のモデル全体がそれまでに捨てられなければ、128ビットに到達するでしょう。
また、何かを 32 ビットから 64 ビットにアップグレードすると、ほとんどのシナリオですぐにパフォーマンス ホールが発生することにも注意してください (これが、Visual Studio 2010 が 32 ビットのみのままである主な理由です)。64 ビットから 128 ビットでも同じことが起こります。オブジェクトが小さいほど、ポインターが多くなり、現在は2 倍の大きさになり、同じことを行うために渡すデータが多くなります。特に、アドレス指定可能なメモリ領域があまり必要ない場合はそうです。
于 2010-04-12T12:41:36.777 に答える
3
nビットアーキテクチャについて話すとき、私たちはしばしば2つのかなり異なることを混同しています。
（1）nビットアドレス指定。たとえば、32ビットアドレスレジスタと32ビットアドレスバスを備えたCPUは、4GBの物理メモリをアドレス指定できます。
（2）CPU内部データパスと汎用レジスタのサイズ。たとえば、32ビット内部アーキテクチャを備えたCPUには、32ビットレジスタ、32ビット整数ALU、32ビット内部データパスなどがあります。
多くの場合、（1）と（2）は同じですが、多くの例外があり、これはますます当てはまる可能性があります。たとえば、近い将来、64ビットを超えるアドレス指定は必要ないかもしれませんが、64ビットを超える必要があるかもしれません。レジスタとデータパスのビット（これは、SIMDをサポートする多くのCPUにすでに当てはまります）。
したがって、要するに、たとえば「64ビットCPU」について話すときは注意する必要があります。これは、さまざまなコンテキストでさまざまなことを意味する可能性があります。
于 2010-04-12T12:49:55.167 に答える
2
料金。また、128 ビット アーキテクチャによって何が得られると思いますか? メモリアドレッシングなどですが、それを効果的に処理するには、より高い帯域幅のバスと、基本的にそれを処理するいくつかの新しい命令言語が必要です。アドレッシングには 64 ビットで十分です (18446744073709551616 バイト)。
HDD には、RAM などに追いつく余地がまだ少しあります。それらはまだ IO のボトルネックになると思います。さらに、新しいチップは、言語に大幅な変更を加えるのではなく、より多くのコアをサポートしているだけです.
于 2010-04-12T12:45:08.670 に答える
1
また、現時点で 128 ビットが非現実的である理由について、コンピューター アーキテクトの見解を示したいと思います。
エネルギーコスト。Bill Dally のプレゼンテーションを参照してください。現在、プロセッサのほとんどのエネルギーがデータの移動に費やされています (ワイヤで消費されています)。ただし、128 ビット計算の最上位ビットはほとんど変化しないため、この問題は軽減されます。
ほとんどの算術演算には、オペランド サイズに関して非線形のコストがあります。
a. ツリー乗算器は、ビット数に関して n^2 のスペースの複雑さを持ちます。
b. 階層キャリールックアヘッド加算器の遅延は、Log[n] wrtビット数です（私は思います）。したがって、128 ビットの加算器は 64 ビットの加算よりも遅くなります。誰かが具体的な数字を教えてもらえますか (Log[n] は非常に安いようです) ?
128 ビット整数または 4 倍精度浮動小数点を使用するプログラムはほとんどありません。使用する場合は、32 ビットまたは 64 ビット演算からそれらを構成する効率的な方法があります。
于 2013-07-15T01:04:07.960 に答える
1
私はたまたまプロのコンピューター アーキテクトです (私の発明は、おそらくあなたがこれを読んでいるコンピューターに組み込まれています)。64 ビットを超えるアドレスを持つプロセッサの開発に従事する報酬はまだもらっていませんが、いくつかのことは知っています。行ってきた私の友達。
そして、私は数十年間、楽しみのために 128 ビット アーキテクチャで遊んでいます。
つまり、すでに起こっています。
実際、それはすでに限られた範囲で起こっています。HP Precision Architecture、Intel Itanium、および IBM Power ラインの上位バージョンには、私がフォールド仮想メモリと呼ぶものがあります。これらについては他の場所で説明しました。たとえば、comp.arch の投稿で詳細を説明しています。 f62404dd5782f309
これらの comp-arch.net wiki 投稿を作成する必要があります。
ただし、これらのプロセッサのマニュアルを入手して、自分で読むことができます。
たとえば、64 ビットのユーザー仮想アドレスから始めることができます。上位 8 ビットは、リージョン テーブルのインデックスに使用できます。このテーブルは、残りの 64-8=56 ビットと連結された上位 24 ビットを返し、80 ビットの拡張仮想アドレスを生成します。次に、TLB、ページテーブル、およびハッシュルックアップによって、通常どおり、物理アドレスが何であれ変換されます。
なぜ 64 から 80 に変更するのですか?
その理由の 1 つは共有ライブラリです。TLB エントリを共有できるように、共有ライブラリをすべてのプロセッサで同じ拡張仮想アドレスに配置したい場合があります。ただし、言語ツールによっては、それらを別のユーザー仮想アドレスに再配置する必要がある場合があります。折り畳まれた仮想アドレスはこれを可能にします。
折り畳まれた仮想アドレスは、ユーザーが使用できる 64 ビットを超える仮想アドレスではありません。
さらに言えば、64 ビットを超えるポインタに対する多くの提案があります。たとえば、ポインタが 64 ビット アドレス、64 ビットの下限と上限、およびメタデータで構成され、合計 128 ビットになるものに取り組みました。境界チェック。ただし、これらは 64 ビットを超えるポインタまたは機能を備えていますが、真に 64 ビットを超える仮想アドレスではありません。
Linus が 128 ビットの仮想アドレスについてhttp://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=103574&threadid=103545&roomid=2に投稿しています。
于 2012-01-06T08:21:11.713 に答える
0
64 ビット プロセッサの主な必要性は、より多くのメモリに対応することであり、それが 64 ビットに切り替える原動力となっています。32 ビット システムでは、少なくともプロセスごとに、実際には 4Gb の RAM しかアドレス指定できません。4GBは少ないです。
64 ビットは、数ペタバイトのアドレス空間を提供します (ただし、現在の 64 ビット ハードウェアの多くは、「48 ビットしか」アドレス指定できませんが、それでも 256 テラバイトの RAM をサポートするには十分です)。
ただし、プロセッサの自然な整数サイズを大きくしても、自動的に「良く」なるわけではありません。トレードオフがあります。128ビットでは、一般的なデータ型の64ビットと比較して2倍のストレージ（レジスタ/ RAM /キャッシュ/など）が必要になります-データを保存するために必要なRAMが増え、送信するデータが増える=遅い、より広いバスには、より多くの物理スペース/おそらくより多くの電力などが必要になる場合があります。
于 2010-04-12T12:59:44.403 に答える
0
プロセッサのアーキテクチャにおける次の大きなものは、量子コンピューティングです。0 または 1 になるだけでなく、qbit には 0 または 1 になる確率があります。
これにより、アルゴリズムのパフォーマンスが大幅に向上します (たとえば、RSA 秘密鍵/公開鍵を非常に簡単に解読できます)。
詳細については、 http://en.wikipedia.org/wiki/Quantum_computerを確認してください。15 年後にお会いしましょう ;-)
于 2010-04-12T12:44:29.257 に答える