インタープリター型言語を書く場合、弱い型付けと強い型付けのどちらが速いですか?
多くの場合、より高速な動的型付けインタープリター言語 (Lua、Javascript) があり、実際、ほとんどのインタープリター言語は弱い型付けを使用しているため、私はこれを疑問に思っていました。
しかし一方で、強い型付けは弱い型付けが保証しないという保証を与えます。
厳密に型指定されているとは、型間の暗黙的な変換がないことを意味します。たとえば、これは強く型付けされた言語では違法ですが、(おそらく) 弱く型付けされた言語では合法です: "5" * 2 == 10. 特に Javascript は、これらの型変換で有名です。
「強く型付けされたインタープリター言語」がないため（質問のコメントから理解した定義を使用して）、明示的な例で質問に答えるのが難しいように思えます。
解釈され、暗黙の変換を持たない言語は考えられません。そして、これには2つの理由があると思います：
解釈された言語は、静的に型付けされない傾向があります。これは、静的に型付けされた言語を実装する場合、歴史的にコンパイルが比較的簡単で、パフォーマンスが大幅に向上するためだと思います。
言語が静的に型付けされていない場合、暗黙的な変換が強制されます。代わりの方法は、プログラマーの負担になります (実行時エラーを回避するために、ソースでは見えない型を追跡する必要があります)。
したがって、実際には、すべてのインタープリター言語は弱く型付けされています。しかし、パフォーマンスの増減の問題は、そうでないものとの比較を意味します。少なくとも、さまざまな既存の実装戦略について議論したい場合はそうです。
ここで、「まあ、想像してみてください」と答えるかもしれません。わかった。したがって、実行時に変換の必要性を検出するコードと、プログラマーが明示的に変換を追加したコードとのパフォーマンスの違いを求めています。その場合、変換の必要性を動的に検出することと、プログラマによって指定された明示的な関数を呼び出すことの違いを比較しています。
一見すると、検出は常にいくらかのオーバーヘッドを追加します (jit によって改善できる [後期] コンパイル済み言語では、インタプリタについて質問しています)。ただし、フェイルファスト動作 (型エラー) が必要な場合は、明示的な変換でも型をチェックする必要があります。実際には、違いは比較的小さいと思います。
そして、これは元のポイントにフィードバックします-弱い型付けのパフォーマンスコストは低く（問題の他のすべての制約/仮定を考えると）、代替の使いやすさのコストは高いため、ほとんどの（すべて？）インタープリター言語は暗黙的にサポートします変換。
[まだ理解できていない場合は申し訳ありません。質問とこの回答が面白くないように見えるので、何かが足りないのではないかと心配しています...]
[edit: maybe a better way of asking the same(?) thing would be something like "what are the comparative advantages/disadvantages of the various ways that dynamic (late binding?) languages handle type conversion?" because i think there you could argue that python's approach is particularly powerful (expressive), while having similar costs to other interpreted languages (and the question avoids having to argue whether python or any other language is "weakly typed" or not).]
強く型付けされているとは、型間の暗黙的な変換がないことを意味します。
"5" * 2 == 10
問題は、「弱い型付け」は明確に定義された用語ではないということです。これは、「暗黙の変換」などの2つの非常に異なる方法があり、パフォーマンスにほとんど逆の影響を与えるためです。