前回の続きです。
32-bitプロセッサは、80386以降、メインフレームの技術を吸収し続けてきた。キャッシュメモリ、パイプライン、スーパースカラ等々、枚挙に暇がないほどである。そして、それらをソフトウェアがサポートし、今や32-bitプロセッサとそのソフトウェア技術は円熟の域に達している。それはPCに搭載されるメモリ（RAM）容量に象徴されるように、リニアアドレス空間の上限である4GBという容量が搭載可能であるものも出てきていることに示されている。
よって、32-bitの次は64-bitだというのは正しい流れである。だが、32-bitへの跳躍の時とは違い、64-bitへの跳躍にはメインフレームのような模範とすべきものがない。技術的には、マルチプロセッサへの領域がまだまだではあるが、PCの世界で独自に64-bitの価値を生み出していかなければならない。
もちろん、PCサーバのような用途では、当の昔に32-bitでの限界は示され、それに対する拡張は32-bitプロセッサ時代から行われていた。それは、アドレス空間の拡張である。32-bitプロセッサのアドレス空間は、32-bitの最大値（＝2の32乗＝4GB）が上限となる。なので、4GBまでのメモリ空間を扱えるかといえば、一方で正しいが、4GBのメモリがなくてもアドレス空間は足りなくなることがある。それは、仮想アドレスを活用し、データをアドレス空間にマッピングするという手法がデータベースソフトウェアで重用されるようになると、「アドレス空間＝データベース空間」となることから、大量のデータを扱うデータベースソフトウェアでは、あっという間にアドレス空間の枯渇問題が発生した。
80386（IA-32）でもセグメントを利用すれば、計4GB超のデータを扱うことは可能となる。ただし、連続したアドレス（リニアアドレス）は最大4GBまでなので、それを超えるものを扱うには、処理に多くの時間を費やすセグメントを利用せざるを得ない。これでは、パフォーマンスが著しく低下するのは明らかなので、データベースソフトウェアではアドレス空間の拡張が望まれた。これは、広大なアドレス空間を必要とするものはすべて同じ事情なので、64-bitアドレス空間（現在の64-bitプロセッサは真に64-bit長のアドレスではなく、48-bit長等、短いものとなっている）をサポートするものが同じく望まれた。メインフレーム系が64-bitにいち早く進化したのは、こういった事情からであり、ダウンサイジング（既に死語扱いか）の中でこれら用途のPC（PCサーバ等）も同じような64-bitプロセッサの採用が求められたのである。
だが、PCサーバや大容量データを扱うもの以外ではどうだろうか。ハードウェアレベルでは、先にふれたように32-bitプロセッサのリニアアドレス上限である4GBものメモリを搭載することも珍しくなく、ソフトウェアもWindows Vistaによって32-bit（IA-32）の機能を有効活用できるようになっており、ここに来て32-bit時代は完全に円熟期を迎えている。しかし、64-bitプロセッサの必要性は、まだまだこれからと言わざるを得ない。
次回に続きます。
コメント