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

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

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

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

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

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

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

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

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

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