типизированной Ракетка Optimizer

Question

Я учусь некоторые типизированных ракетки на данный момент, и у меня есть несколько философской дилемма:

Ракетка претендует быть основой развития языка и типизированная Ракеткой является одним из таких языков, реализованных на нем. В документации упоминается, что из-за используемых типов компилятор теперь может сделать больше/лучше оптимизацию.

Конкретный вопрос:

Где эти оптимизации происходит?

1) В компиляции/развернуть часть (которая «программируемая» как часть структуры языка здания)

-или-

2) далее вниз по линии в (байт-код) оптимизатора (который написан на C, а не напрямую модифицируется через фреймворк).

Если 2) истинно, означает ли это, что информация о типе теряется после этапа компиляции/расширения, а затем «перестраивается/угадывается» оптимизатором или имеет промежуточное представление, которое было изменено для размещения информации о типе и последующего информирования этапы о них?

Причина, по которой я задаю этот конкретный вопрос, состоит в том, что я хочу получить представление о том, насколько на самом деле существует рамочная система Racket, т. Е. Также жизнеспособна для статически типизированных языков без каких-либо изменений в бэкэнде или системе типов передняя часть, а код во время выполнения все еще динамически вводится (но, конечно, статически проверяется).

спасибо.

Answer 1

Типизированные оптимизации Racket происходят во время расширения макросов. Чтобы убедиться в этом, вы можете изменить #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 может вывести информацию о типе, которая не отображается при увеличении времени макросов. Они не контролируются пользователем, но вам не нужно полагаться на них.