StackOverflowに関するすべてのコンパイラ設計者へのご挨拶。
私は現在、ハイパフォーマンスコンピューティングで使用するための新しいスクリプト言語の開発に焦点を当てたプロジェクトに取り組んでいます。ソースコードは最初にバイトコード表現にコンパイルされます。次に、バイトコードはランタイムによってロードされます。ランタイムは、その上で積極的な（そしておそらく時間のかかる）最適化を実行します（これは、ほとんどの「先行」コンパイラーが行うよりもはるかに進んでいます。結局のところ、それが全体のポイントです。事業）。このプロセスの結果はまだバイトコードであることに注意してください。
次に、バイトコードが仮想マシンで実行されます。現在、この仮想マシンは、単純なジャンプテーブルとメッセージポンプを使用して実装されています。仮想マシンは、ポインターを使用してバイトコードを実行し、ポインターの下に命令をロードし、ジャンプテーブルで命令ハンドラーを検索して、そこにジャンプします。命令ハンドラは適切なアクションを実行し、最後に制御をメッセージループに戻します。仮想マシンの命令ポインタがインクリメントされ、プロセス全体が最初からやり直されます。このアプローチで達成できるパフォーマンスは、実際には非常に素晴らしいものです。もちろん、実際の命令ハンドラーのコードも手作業で微調整されています。
現在、ほとんどの「プロフェッショナル」ランタイム環境（Java、.NETなど）は、実行前にバイトコードをネイティブコードに変換するためにジャストインタイムコンパイルを使用しています。JITを使用するVMは通常、バイトコードインタープリターよりもはるかに優れたパフォーマンスを発揮します。ここで問題となるのは、インタプリタが基本的に行うのは、命令をロードしてジャンプテーブルでジャンプターゲットを検索することだけなので（命令ハンドラ自体はインタプリタに静的にコンパイルされているため、すでにネイティブコードであることに注意してください）、ジャストインタイムコンパイルはパフォーマンスの向上につながりますか、それとも実際にパフォーマンスを低下させますか？通訳のジャンプテーブルがパフォーマンスを低下させるとは本当に想像できません。JITerを使用してそのコードをコンパイルするために費やされた時間を補うために多くのことをします。JITerがコードに対して追加の最適化を実行できることは理解していますが、私の場合、実行前にバイトコードレベルで非常に積極的な最適化がすでに実行されています。インタプリタをJITコンパイラに置き換えることで、もっとスピードを上げることができると思いますか？もしそうなら、なぜですか？
アプローチとベンチマークの両方を実装することで、この質問に対する最も正確な答えが得られることを理解していますが、明確な答えがある場合は、時間の価値がない可能性があります。
ありがとう。