>>169
JavaはCPUというかハードウェアの違いをVM(バーチャルマシン・仮想機械)
として抽象化して異なるハードウェアにはVMだけ移植すれば
互換性がとれてｳﾏｰ!
という理屈なんだけど、別に最低ラインがVMだというだけであって、
WINTEL用にはネイティブコードコンパイラがついていたって何もおかしく
ありません(GNU のコンパイラはJavaからネイティブコードにコンパイル
してくれるはず)。とはいってもクラスファイルになったバイトコードだけ
を他のハードウェアにも漏っていって実行したい(アプレットとか)という
欲望があるために、JIT(ジャストインタイムコンパイルだっけ?)
という(Cecil(かな)かsmalltalkのベンダーから勝ったのかな..)
RAMの中でコンパイルして実行というしかけがあって、いまはHotSpotとか
いってるけどまだ遅いのでしょうか?

perl, python, ruby などのスクリプト言語もｵｾｰﾖ!と
ネイティブコードコンパイルしていないのがバレると言われがちですが、
じゃあ単純にコンパイルすれば速いのかといわれれば、これらの言語は
動的な型付けをもつために実行時に正しい型かどうかのチェックを
しなければならず、意外に遅いままだったりします。
これは、Perl の B コンパイラだっけ? とか GCL (Cに変換)でやってみれば
実感できます。

あっと、これらの言語では(たぶん)、変数の値はその言語でのオブジェクトに
対するポインタですべてを表します。
そんでアラインメントの関係で一番下(LSB)が自由に使えたりするので
それでfixnumとオブジェクトへのポインタを区別するとか
涙ぐましい努力をします。(ここらへんのテクニックは論文になっていて
NECの論文データべーすで見付かります)

じゃあ、速くするためにはどうしたらいいのかといえば、データの型を
コンパイル時にあらかじめ予測するとか、型の宣言をどうしても必要な
ときだけプログラマーにしてもらうということになります。

そんで Common Lisp にはその型宣言が用意されています。そんだけ。