キロバイトブロックとポインターのすべての可能な順列のメモリは可能ですか？

これは頭​​をかき回すのに十分なほど難しい考えであり、編集/ヘルプを知っている人にとって読みやすくするためにどんな編集/ヘルプも大いに感謝します。

理論上、1キロバイトのすべての可能なバイナリ順列のコピーを1つ保存したハードドライブを使用し、システムの残りの部分にこれらの場所へのポインターを作成させることは可能ですか？

このような方法で作成されたシステムは、単に情報を直接保存するよりも速いでしょうか？

別の方法を説明するには、文章を書く代わりに次のように言います。

「こんにちは、ボブです。」「そのサンドイッチは美味しそうです。」

...ハードドライブに保存すると、アルファベットやその他の文字のすべての順列が最大数（たとえば1000文字程度）になり、次のような文が保存されます。

[ポインター＃21381723]

2つの⁸¹⁹²種類の異なる1Kブロックがあります。それらをすべて保存するには、2つの⁸²⁰²ビットのストレージが必要です。宇宙はたったの約10含まれているので⁸⁰（または〜2 ²⁶⁶）粒子を、いることを安全な賭けだではありませんそれらすべてを保存することができ、そしてあなたはそれが時間を節約したりしませんかどうかについて疑問に持っていません。

しかし、実際には、これに答えるより興味深い方法があります。定数の巨大なプールにインデックスを作成することを提案しています。しかし、どのインデックスを逆参照するかをどのようにして知るのでしょうか？あなただけの1文字のブロックを格納したいという主張のために想像：a、b、cそれはこれらのブロックを格納する最も効率的なレイアウトだから...おそらくあなたのインデックスは、0、1、2などになります。

取り決めについて何かお気づきですか？実際、インデックスは保存されたデータのコード化された表現です！つまり、インデックスを参照解除する必要はなく、インデックスを必要なデータに変換するだけです。

何かの可能な値をすべてテーブルに保存すると、これは常に起こります。インデックスは単にデータ自体のエンコードされたバージョンになるため、最初からデータを保存する必要がなくなります。これが実際の世界では、インデックスはスパースデータに対してのみ有用です（たとえば、訪問したすべてのWebページ、存在する可能性のあるすべてのWebページ、または存在するすべてのWebページでさえありません）。

他の人がすでに指摘しているように、1kブロックに対して2 ^ 8192の可能性があります。つまり、すべてのブロックアドレスが同じビット数でエンコードされている場合、ブロックのアドレスをエンコードするには8192ビットが必要になるため、アドレスは1kになります。間接的なレイヤーを追加する以外は何も得られないので、パフォーマンスは得られません。

短いアドレスにしたい場合は、いくつかのブロックを短いアドレスでエンコードし、いくつかを長いアドレスでエンコードし、長いブロックがそれほど頻繁に表示されないようにする必要があります。ハフマン符号）。それには、保存する前に保存しているデータの知識、またはエンコーディングの定期的な変更が必要になります。また、さまざまな長さのブロックを使用する他の圧縮アルゴリズムよりも効率が低い可能性があります。

それには2つの問題があります。

まず、「1キロバイトのすべての可能なバイナリ順列」は膨大な量のデータです。1024バイト* 1バイトあたり8ビット= 1キロバイトで8192ビット。可能なすべての順列は2 ^ 8192です。それは約1.09e+2466キロバイトです！（比較のために、1 TBドライブは1e09キロバイトです。）

第二に、そのような巨大なテーブルがあり、ポインターでインデックスを付けたとしても、正確に1 KBより小さいデータを参照したい場合はどうしますか？

他のポスターが指摘しているように、ある時点で、可能なすべての値のリストにインデックスを付けるために必要なポインターのサイズは、ゲインを無効にします。

ただし、一部の言語では、メモリ使用量を最適化するために、提案されたものの限定バージョンを使用しています。Pythonは文字列「interning」を使用して、メモリ内の重複文字列の数を減らします。「python string intern」を検索すると、詳細情報を見つけることができます。