型付きラケットオプティマイザ

Question

私は、現時点では、いくつかの型指定されたラケットを学んでいると私はやや哲学的ジレンマを持っている：

ラケットは、言語の開発フレームワークであることを主張し、型指定されたラケットは、その上に実装されそのような言語です。ドキュメントでは、型の使用により、コンパイラはより良い/より良い最適化を行うことができると述べています。

具体的な質問：

これらの最適化はどこで行われますか？コンパイルにおいて

1）/拡張言語構築フレームワークの一部としての「プログラム可能」である部分（）

- または -

2）さらに（バイトコード）オプティマイザの行ダウン（これはC言語で書かれており、フレームワークを介して直接修正することはできません）。

2）が真である場合、タイプ情報がコンパイル/展開段階の後に失われ、後でオプティマイザによって「再構築/推測」されるか、または中間情報が型情報に対応して後で通知される彼らについての段階？

私はこの特定の質問をしている理由は、私はラケット言語のフレームワークが本当にどのように一般的であるかの感情を得たいからです。つまり、タイプシステムとバックエンドの変更なしで静的な型付き言語フロントエンドのものですが、実行時のコードは動的に型付けされています（ただし静的にチェックされています）。

ありがとうございます。

Answer 1

マクロ展開時に型付きラケットの最適化が行われます。 #lang typed/racketを#lang typed/racket #:no-optimizeに変更すると、Typed Racketはどのような最適化が適用されるかを完全に制御できます。

最適化は、タイプ情報を使用して、特定のプロシージャのさまざまな用途をtheir unsafe equivalentsに置き換えます。安全でないプロシージャーは、引数の型のランタイムチェックを実行せず、誤って使用されると未定義の動作（read：segfaults）を引き起こします。詳しくは、Optimization in Typed Racketというドキュメントのセクションを参照してください。

プロシージャの安全でない変種を公開することで、ユーザー定義言語でこれらの最適化を実現することができます。たとえば、範囲外のインデックスでベクトルにアクセスしなかったことを証明できるタイプシステムで独自の言語を書いた場合、vector-refの使用をunsafe-vector-refに置き換えることができます。

バイトコードレベルでも同様の最適化が行われていますが、JITがマクロ展開時に表示されないタイプの情報を推測できる場合は、ほとんどの場合に適用されます。これらはユーザーが制御するものではありませんが、それらに頼る必要はありません。