前回の続きです。
それは、32-bitから64-bitへの跳躍が16-bitから32-bitへの跳躍に比べて、見出すべき価値がほとんどないことである。貧弱なハードウェアリソースであっても、16-bitから32-bitへの移行は、有用な各種機能の大幅な追加によって、大いに意義のあるものであった。だが、32-bitから64-bitへの移行はそうではない。64-bitへの移行を喧伝する側は、仮想実行環境のサポートによる外部攻撃からの脆弱性を抜本的に解消できること、広大なリニアアドレス空間をサポートすることによってのユーザ環境の向上等を謳うが、どう見ても技術的には「跳躍」とは言い難い。一般ユーザから見れば、それはなおのこととなるだろう。
また、64-bit環境は、膨大なリソースを必要とする。プログラムが32-bitから64-bitに拡張されるだけで、バイナリサイズは拡大し、それはアドレス・メモリ空間や各種バス（プロセッサ－メモリ間、メモリ－HDD間等々）を圧迫する。これもいい喩えではないが、いくら台所に野菜と皿の枚数を増やしたところで、台所で調理する人が一人しかいない、あるいは調理する人が数十人いても台所のスペースが10平方メートル程度の広さしかなければ、せっかくの大量の野菜や皿が供給されたとしても、お皿にきれいに盛り付けられた野菜サラダを大量に作ることができないのと同じである。
一般的には、同じリソースであり、かつ、そのキャパシティが32-bitプロセッサの処理の範囲内であれば、64-bitプロセッサにおける64-bit環境の方が確実に低パフォーマンスとなる。無論、32-bitプロセッサの処理の範囲外であれば、64-bit環境の方が高パフォーマンスを示すこともあるが、現在の一般的なPCにおいては、64-bit環境よりも32-bit環境の方が低リソース利用・高パフォーマンス処理速度である。
これが逆転するのは、64-bit環境に十分なリソースとハードウェア環境が用意された時である。具体的な数字を示すのは難しいが、少なくとも搭載するRAMは8GB超、各種バスの能力は現行の4倍以上は必要だろう。それらが揃って、初めて一般ユーザにとっての64-bitプロセッサの有用性が出てくるようになる。無論、それだけのリソースとハードウェア環境を活かすだけのソフトウェアが必要なのも言うまでもない。それには、ほぼ間違いなくユーザインタフェースの革新が求められる。キーボードとキャラクタ（文字）のみのユーザインタフェースであれば、今の32-bit環境でさえゴージャス過ぎ、ビットマップディスプレイ上でのマウスとアイコン（絵文字）によるユーザインタフェースの革新があって、ようやく32-bit環境に相応しいものとなった。64-bit環境では、さらに多くのリソースが必要となるユーザインタフェースが出てくるだろうが、それが何であるかはまだわからない。既に生まれている技術なのか、まったく未知なる技術なのか。
さて、話が逸れそうなので、総括しよう。「64-bitは今、本当に必要か？」という問いに対し、私は以上のことから、多くの一般的なPCユーザにとっては時期尚早だと考える。Windows VistaやWindows XPに限って言ってもそうなるが、64-bit環境はまだまだハードウェアをサポートするデバイスドライバすら不足している状況であり、使うだけでも多くの苦労をユーザに強いるものである。さらに、そこまでして苦労して用意する64-bit環境も、ハードウェアリソースの欠乏によって、32-bit環境と大して変わらないばかりか、逆に32-bit環境よりも劣ることも少なくない。
もちろん、積極的に64-bit環境が必要なPCサーバのようなジャンルがあるのも確かである。大量演算処理が中心であり、特に巨大データベースを扱うようなものでは、逆に64-bit環境を利用しない方がナンセンスである。64-bit環境は、いかなる必要性によって指向され、それがどのように利用されるのか。ハードウェアリソースは十分か、等々、きちんと明確な理由があって導入するなら大いに意義はあるが、単に使ってみたいとか、セールストークに踊らされるだけでは無意味である（趣味的に利用したいとか、64-bit対応のプログラミング環境を整えるとかなら意義はある）。以上をよく考慮に入れて、64-bitプロセッサを活かしていこう。
コメント