Почему оптимизация целых программ сейчас не распространена? - PullRequest
5 голосов
/ 05 августа 2010

Основной вопрос: почему общие или даже специализированные оптимизаторы целых программ не являются частью нашей повседневной жизни?

Я начал думать об этом после прочтения Белой книги SuperCompilers, LLC, в которой обсуждаетсяих метод «суперкомпиляции» или метакомпиляции источника программы (как правило) для достижения более быстрой версии, которая выполняет те же функции, что и исходная программа.По сути, они выполняют выполнение программы и перекомпилируются на один и тот же целевой язык.При этом происходят естественные оптимизации;Например, общая функция двоичного поиска может быть специализированной для двоичного поиска в массиве из 100 элементов, если входная программа часто использует массивы из 100 элементов.

Частичная оценка , возможно, является болееузкий тип оптимизации всей программы, где источник программы уменьшается / оценивается на основе некоторого фиксированного набора входных данных, оставляя при этом неизвестный вход открытым для оценки во время выполнения.Например, общая функция x ^ y, если задано, что y = 5, может быть уменьшена до x ^ 5 или, возможно, что-то вроде (x * x) * (x * x) * x.

(Iизвиняюсь за мои грубые описания этих двух методов)

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

  • Это страх (программист боится преобразования своего кода, вносящего ошибки)?
  • Это просто не стоит (то есть, для веб-приложений узким местом является ввод / вывод, и этот вид оптимизации, по-видимому, экономит процессорное время)?
  • Этот тип программного обеспечения так сложно написать?
  • Или моё восприятие всего этого неверно?

Ответы [ 3 ]

3 голосов
/ 05 августа 2010

Я думаю, что в основном ваше восприятие неверно. Большинство компиляторов поддерживают оптимизацию "всей программы" (межпроцедурную) и оптимизацию на основе профилей, чтобы направлять оптимизатор на основе фактического использования.

Основная причина, по которой большинство людей не заметили, заключается в том, что, в конце концов, они редко дают достаточно различий, чтобы действительно заметить, что они очень заботятся. Общая доступность таких инструментов также произошла в то время, когда они просто не имели большого значения для большинства целей. Процессоры теперь настолько быстры, что никто не задумывается о том, чтобы запустить код на виртуальной машине Java, которая сама по себе работает на чем-то вроде виртуальной машины VMWare (и даже не было бы особенно редко иметь третий уровень виртуальной машины).

Это добавляет дополнительные издержки, которые карлики - улучшение, которое вы обычно можете ожидать от глобальной оптимизации. Для большинства людей разница в скорости должна быть весьма большой, чтобы вообще иметь значение (а улучшения от глобальной оптимизации редко можно назвать).

0 голосов
/ 04 января 2015

Спасибо за вопрос, который я считаю глубоким вопросом, и пожалуйста, прости мое пламя ...

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

Всякий раз, когда вы пишете программу A, которая пишет программу B (это базовый навык, который каждый программист (по моему мнению) должен знать, как использовать, и , когда использовать), вы выполняете частичную оценку , Поскольку некоторые входные данные известны на ранних этапах и не часто меняются, программе не нужно постоянно проверять, что это такое. Вы можете взять информацию, которая вряд ли когда-либо изменится, и передать ее в качестве входных данных A, и заставить A распечатать программу B, которая просто «знает» статический ввод, поэтому все, что от нее требуется, - это обработать непредсказуемый динамический ввод.

Но как только кто-то пытается написать инструмент для частичной оценки, он выводит мозг программиста из цикла, и это его убивает.

То же самое относится и к оптимизации. Когда программист уступает свое суждение инструменту, очень мало результатов, потому что нет инструмента (пока, по крайней мере), который мог бы постичь код так, как программист.

Конечно, стоит попытаться создать инструменты, которые понимают код так же, как программист, но глупо полагать, что было выполнено.

0 голосов
/ 03 января 2015

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

С помощью Supercompilation (SC) программист может написать более абстрактный код, не оплачивая затраты времени выполнения (для сборки выпуска, это можетнепрактично делать это для каждой отладочной сборки).

Таким образом, если (сегодня) нет SC, то программисты пишут код «низкого уровня», поэтому никто не пишет лучший код и ему нужны SC для выполнения тяжелой работы.

Единственное, что можетПредотвращение SC в реальном мире - это необходимость (очень) высокого уровня интеллекта для всей суперкомпиляции программы.OpenCog или любой другой искусственный интеллект AI может помочь в решении этой последней проблемы.Это не тот случай, когда SC должны обрабатывать только мелкие детали (как одиночные методы).

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

С более абстрактным кодом я имею в виду

  • способность писатькод, независимый от типа данных, так что в конце концов он сделает шаблоны / шаблоны устаревшими (по большей части)
  • программист может вызвать в любой точке любой интерпретатор, в большинстве случаев SC должен быть в состояниичтобы полностью его оптимизировать, чтобы конечный результат выглядел как версия кода, созданная вручную программистом.Без необходимости выполнять ручное «развертывание» и значительно более высокую производительность (поскольку программисту не нужно изменять код «низкого уровня», он может работать на более высоком уровне
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...