Языки и виртуальные машины:Функции, которые трудно оптимизировать и почему

Question

Я провожу обзор функций в рамках подготовки к исследовательскому проекту.

Назовите основной язык или языковую функцию, которую трудно оптимизировать, и почему эта функция стоит или не стоит заплаченной цены, или вместо этого просто опровергните мои теории ниже с помощью неподтвержденных фактов.Прежде чем кто-либо сочтет это субъективным, я прошу предоставить конкретные примеры языков или функций, а также идеи по оптимизации этих функций или важные функции, которые я не рассматривал.Кроме того, любые ссылки на реализации, которые доказывают правильность или неправильность моих теорий.

Первое место в моем списке трудно оптимизируемых функций и моих теорий (некоторые из моих теорий непроверены и основаны на мысленных экспериментах):

1) Перегрузка метода времени выполнения (также известная как отправка несколькими методами или отправка на основе подписи).Сложно ли оптимизировать в сочетании с функциями, которые допускают перекомпиляцию во время выполнения или добавление метода.Или это все равно просто тяжело?Кэширование сайта вызовов является обычной оптимизацией для многих систем выполнения, но мультиметодизация добавляет дополнительную сложность, а также делает ее менее практичной для встроенных методов.

2) Изменение типа / варианты (он же типизация на основе значений, в отличие от типизации на основе переменных) Традиционные оптимизации просто не могут быть применены, когда вы не знаете, может ли тип чего-либо измениться в базовом блоке.В сочетании с несколькими методами встраивание должно выполняться осторожно, если вообще выполняется, и, вероятно, только при заданном пороговом размере вызываемого абонента.т. е.легко рассмотреть возможность встраивания простых выборок свойств (getters / setters), но встраивание сложных методов может привести к раздуванию кода.Другая проблема заключается в том, что я не могу просто назначить вариант регистру и привязать его к собственным инструкциям, потому что мне приходится переносить информацию о типе, или для каждой переменной требуется 2 регистра вместо 1.На IA-32 это неудобно, даже если улучшено с помощью дополнительных регистров x64.Вероятно, это моя любимая функция динамических языков, поскольку она упрощает очень многие вещи с точки зрения программиста.

3) Первоклассные продолжения - Существует несколько способов их реализации, и я сделал это в обоих наиболее распространенных подходах, один из которых заключается в копировании стека, а другой - в реализации среды выполнения для использования стиля передачи продолжения, стеков cactus, фреймов стека копирования при записи и сборки мусора.Продолжения первого класса имеют проблемы с управлением ресурсами, т.е.мы должны сохранить все на случай, если продолжение будет возобновлено, и я не знаю, поддерживают ли какие-либо языки оставление продолжения с "намерением" (т.Е."Я не вернусь сюда, так что вы можете выбросить эту копию мира").Запрограммировав в потоковой модели и модели продолжения, я знаю, что обе могут выполнять одно и то же, но элегантность продолжений значительно усложняет среду выполнения, а также может повлиять на эффективность кэша (локальность стека больше изменяется при использовании продолжений и совместных подпрограмм).Другая проблема заключается в том, что они просто не привязаны к оборудованию.Оптимизация продолжений - это оптимизация для менее распространенного случая, и, как мы знаем, общий случай должен быть быстрым, а менее распространенные случаи должны быть правильными.

4) Арифметика указателей и возможность маскировать указатели (хранение в целых числах и т.д.) Пришлось добавить это, но на самом деле я мог бы довольно легко прожить без этого.

По моим ощущениям, многие высокоуровневые функции, особенно в динамических языках просто не привязывайтесь к оборудованию.На оптимизацию микропроцессорных реализаций в чипе потрачены миллиарды долларов исследований, однако выбор языковой функции (ов) может привести к маргинализации многих из этих функций (таких функций, как кэширование, преобразование верхней части стека в регистр, параллелизм команд, буферы обратного адреса, буферы циклов и предсказание ветвлений).Макроприложения микрофункций не обязательно выполняются так, как любят думать некоторые разработчики, и реализация многих языков в виртуальной машине приводит к отображению собственных операций в вызовы функций (т.Е.чем динамичнее язык, тем больше мы должны искать / кэшировать во время выполнения, ничего нельзя предполагать, поэтому наш набор команд состоит из более высокого процента нелокального ветвления, чем традиционный, статически скомпилированный код) и единственное, что мы действительно можем хорошо использовать JIT, это вычисление выражений нединамических типов и операций над постоянными или немедленными типами.Я нутром чую, что виртуальные машины с байт-кодом и JIT-ядра, возможно, не всегда оправданы для определенных языков из-за этого.

Я приветствую ваши ответы.

Answer 1

Пара комментариев:

• Все языки с динамической отправкой, даже основанные на одном объекте, кажутся довольно сложными для эффективной реализации.Посмотрите на все усилия, которые были затрачены на оптимизацию Self во время выполнения (или, совсем недавно, JavaScript с помощью SpiderMonkey).

• Не упускайте из виду разделенные продолжения.Жюри все еще не определилось, но их значительно легче оптимизировать, чем классические неограниченные продолжения.Прочтите статью Гасбихлера и Спербера.

Answer 2

Я нутром чувствую, что байт-код виртуальные машины и JIT-ядра возможно, не всегда оправданы для определенных языков из-за этого.

Разве IronPython не был написан для доказательства того, что виртуальная машина не может работать так же хорошо, как собственная реализация языка (Python).А затем автор IronPython испытал настоящий шок, когда узнал, что IronPython действительно хорошо работает для динамического языка на виртуальной машине с байт-кодом?

Собственный Microsoft .Группа Net internals официально заявляет, что, по их мнению, в конечном итоге дрожание превзойдет "обычный" компилятор / компоновщик (скажем, для C / C ++).

Я думаю, присяжные все еще не пришли к согласию по этому поводу.Трудно назвать это в любом случае.Выберите язык, который лучше всего подходит для вашей работы...