64bitどきどき対決(先手オレ)

LP64(longとポインターは64bit)。ほとんどのアプリが64bitモードでリコンパイルされてレポジトリ上に置かれているので、64bitで有ることを意識することはほとんど無い。FirefoxもOpenOffice.orgも64bit。
パフォーマンスに関してはほとんど影響なし。ちょっと実行バイナリの占有するメモリが大きい。

LLP64(long longとポインターは64bit。longは32bit)。リコンパイル程度ではうまく動かないのか64bitアプリは非常に少ない。FirefoxもOpenOffice.orgも32bit版しかない。GIMPは64bit版があって便利。Blenderも64bit版があるな。
その代わり32bitアプリを動かすインターフェースが充実している(32bitモードのアプリであることをほとんど意識しない)。ただし、たまに変な動きをすることも。
CPUの仮想化をうまく使って「本物のWindowsXP(32bit)」でアプリを動かすという荒技も付属。これを使うと、本来サポート対象外のMS SQLServer 7.0なんかまで動いちゃう(具体的にいうと「給与奉行」。貴様のせいでXPを1台残しておく必要があったのだ)。


Win32(x64)じゃなくて、Win64という正式名称だとは思わなかった。ついでに、APIレベルではIA-64(Itanium)とEM64Tで互換性があるのも初めて知った。ま、インストラクション全然違うので、POSIXみたいなソースコードレベルの話だろうけど。
しかし、手元のLinuxは仮想メモリ自体が2.8Gしかないので、64bitメモリ空間を利用することはほとんど無いのでした。mmapくらいかな。とはいえ、mmapで4GByte以上のファイルをマップすることがどれくらいあるかというと微妙だなー。ま、いいや、Ubuntuは再インストールが楽だから、いざとなればSwap増やして再インストールだな。というか、DellのデスクトップのHDDって、どうやれば交換できるんだろう？　マウンタが取り外せないー。
物理メモリは1GByteで全然困りません。OpenOffice.orgのツールバーの書き換えも見えるけど一瞬なので(これは単にCPUが速いせい。64bit関係ない)、なかなか快適です。
(追記)
AMD64/Intel 64では汎用レジスタが8本も増えたのか。C言語だとリコンパイルするだけで結構パフォーマンス上がりそうだな。変数のレジスタマッピングと、それによるレジスタリネーミングでメモリアクセスの機会はかなり減りそう。メモリに書き込む際にはライトバックキャッシュだろうから実行時の速度はレジスタと変わらないにしても主メモリにはき出す機会がないだけでもボトルネックは減るし。だいたい、変数のレジスタマッピングは局所変数に対して行われるものだから、同様のスタックフレームをライトバックしてもほぼ無意味(書き換えたスタックフレームを主記憶に転送する頃にはそのブロックは処理が終わってる)だし。
JavaVMに関してはわかんないなー。そもそもスタックマシンだし。局所変数のレジスタマッピングくらいやってるのかな(Javaは局所変数をスタックフレームにとるとは限らない。実装依存)？