WikiDer > Оптимизация программы

Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) Эта статья возможно содержит оригинальные исследования. Пожалуйста Улучши это к проверка заявленные претензии и добавление встроенные цитаты. Заявления, содержащие только оригинальные исследования, следует удалить. (Сентябрь 2016) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья написано как личное размышление, личное эссе или аргументированное эссе который излагает личные чувства редактора Википедии или представляет оригинальный аргумент по теме. Пожалуйста помогите улучшить это переписав его в энциклопедический стиль. (Июль 2017 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта секция нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. (Февраль 2018 г.) (Узнайте, как и когда удалить этот шаблон сообщения) (Узнайте, как и когда удалить этот шаблон сообщения)

В Информатика, оптимизация программы, оптимизация кода, или же оптимизация программного обеспечения это процесс модификации программной системы, чтобы заставить ее работать больше эффективно или используйте меньше ресурсов.^[1] В целом компьютерная программа может быть оптимизирован, чтобы он выполнялся быстрее, или чтобы он мог работать с меньшими затратами. хранение в памяти или другие ресурсы, или потреблять меньше энергии.

Общий

Хотя слово «оптимизация» имеет тот же корень, что и «оптимальный», процесс оптимизации редко приводит к созданию действительно оптимальной системы. Как правило, систему можно сделать оптимальной не в абсолютном выражении, а только в отношении данной метрики качества, которая может контрастировать с другими возможными метриками. В результате оптимизированная система обычно будет оптимальной только для одного приложения или для одной аудитории. Можно уменьшить количество времени, которое программа тратит на выполнение некоторой задачи, за счет того, что она потребляет больше памяти. В приложении, где объем памяти ограничен, можно сознательно выбрать более медленный алгоритм чтобы использовать меньше памяти. Часто не существует универсального дизайна, подходящего для всех случаев, поэтому инженеры делать компромиссы для оптимизации наиболее интересных атрибутов. Кроме того, усилия, необходимые для того, чтобы сделать часть программного обеспечения полностью оптимальной - неспособной к дальнейшим улучшениям, - почти всегда больше, чем разумно с точки зрения получаемых выгод; поэтому процесс оптимизации может быть остановлен до того, как будет достигнуто полностью оптимальное решение. К счастью, часто самые большие улучшения происходят на ранних этапах процесса.

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

Уровни оптимизации

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

Поскольку производительность является частью спецификации программы - необычно медленная программа не подходит для этой цели: видеоигра с частотой 60 Гц (кадров в секунду) приемлема, но 6 кадров в секунду недопустимо нестабильна - Производительность является предметом рассмотрения с самого начала, чтобы гарантировать, что система способна обеспечить достаточную производительность, а ранние прототипы должны иметь примерно приемлемую производительность, чтобы была уверенность в том, что конечная система (с оптимизацией) достигнет приемлемой производительности. Иногда это опускается, полагая, что оптимизацию всегда можно будет провести позже, в результате чего прототипы систем будут работать слишком медленно - часто порядок величины или более - и системы, которые в конечном итоге терпят неудачу, потому что они архитектурно не могут достичь своих целей производительности, таких как Intel 432 (1981); или те, которые требуют годы работы для достижения приемлемой производительности, например Java (1995), которая достигла приемлемой производительности только с HotSpot (1999). Степень изменения производительности между прототипом и производственной системой и то, насколько она поддается оптимизации, может быть значительным источником неопределенности и риска.

Уровень дизайна

На самом высоком уровне дизайн может быть оптимизирован для наилучшего использования доступных ресурсов с учетом целей, ограничений и ожидаемого использования / нагрузки. Архитектурный дизайн системы в значительной степени влияет на ее производительность. Например, система с привязкой к сетевой задержке (где сетевая задержка является основным ограничением общей производительности) должна быть оптимизирована для минимизации сетевых отключений, в идеале выполняя один запрос (или без запросов, как в протокол push), а не несколько обходов. Выбор дизайна зависит от целей: при проектировании компилятор, если быстрая компиляция является ключевым приоритетом, a однопроходный компилятор быстрее чем многопроходный компилятор (предполагая ту же работу), но если целью является скорость вывода кода, более медленный многопроходный компилятор выполняет задачу лучше, даже если он сам занимает больше времени. Выбор платформы и языка программирования происходит на этом уровне, и их изменение часто требует полной перезаписи, хотя модульная система может допускать перезапись только некоторых компонентов - например, программа Python может перезаписывать критические для производительности разделы на C. система, выбор архитектуры (клиент-сервер, пиринговыйи т. д.) возникает на уровне дизайна, и его может быть сложно изменить, особенно если все компоненты не могут быть заменены синхронно (например, старые клиенты).

Алгоритмы и структуры данных

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

Для алгоритмов это в первую очередь состоит в обеспечении того, чтобы алгоритмы были постоянными O (1), логарифмическими O (log п), линейный O (п) или в некоторых случаях логлинейным O (п бревно п) на входе (как в пространстве, так и во времени). Алгоритмы квадратичной сложности O (п²) не масштабируются, и даже линейные алгоритмы вызывают проблемы при повторном вызове и обычно заменяются постоянными или логарифмическими, если это возможно.

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

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

Уровень исходного кода

Помимо общих алгоритмов и их реализации на абстрактной машине, выбор конкретного уровня исходного кода может иметь большое значение. Например, в ранних компиляторах C пока (1) был медленнее, чем за(;;) для безусловного цикла, потому что пока (1) оценил 1, а затем имел условный переход, который проверял, было ли оно истинным, в то время как за (;;) произошел безусловный прыжок. Некоторые оптимизации (например, эта) в настоящее время могут выполняться оптимизация компиляторов. Это зависит от исходного языка, целевого машинного языка и компилятора и может быть трудным для понимания или прогнозирования и может меняться со временем; это ключевое место, где понимание компиляторов и машинного кода может улучшить производительность. Циклическое движение кода и оптимизация возвращаемого значения являются примерами оптимизаций, которые снижают потребность во вспомогательных переменных и могут даже привести к повышению производительности за счет исключения циклических оптимизаций.

Уровень сборки

Между исходным кодом и уровнем компиляции, директивы и построить флаги можно использовать для настройки параметров производительности в исходном коде и компиляторе соответственно, например, используя препроцессор определяет отключение ненужных программных функций, оптимизацию для конкретных моделей процессоров или аппаратных возможностей или прогнозирование разветвление, например. Системы распространения программного обеспечения на основе исходного кода, такие как BSDс Порты и Gentooс Portage можете воспользоваться этой формой оптимизации.

Уровень компиляции

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

Уровень сборки

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

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

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

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

Время выполнения

Вовремя компиляторы могут создавать настраиваемый машинный код на основе данных времени выполнения за счет накладных расходов на компиляцию. Эта техника относится к самым ранним регулярное выражение движки, и получил широкое распространение в Java HotSpot и V8 для JavaScript. В некоторых случаях адаптивная оптимизация может быть в состоянии выполнить время выполнения оптимизация, превышающая возможности статических компиляторов, путем динамической корректировки параметров в соответствии с фактическими входными данными или другими факторами.

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

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

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

Платформо-зависимые и независимые оптимизации

Оптимизацию кода также можно в общих чертах разделить на Платформа-зависимые и платформенно-независимые методы. Хотя последние эффективны на большинстве или на всех платформах, платформенно-зависимые методы используют определенные свойства одной платформы или полагаются на параметры, зависящие от одной платформы или даже от одного процессора. Поэтому может потребоваться написание или создание разных версий одного и того же кода для разных процессоров. Например, в случае оптимизации на уровне компиляции независимые от платформы методы являются общими методами (такими как разворачивание петли, сокращение числа вызовов функций, подпрограмм, эффективно использующих память, уменьшение условий и т. д.), которые аналогичным образом влияют на большинство архитектур ЦП. Отличный пример независимой от платформы оптимизации был показан с внутренним циклом for, где было замечено, что цикл с внутренним циклом for выполняет больше вычислений в единицу времени, чем цикл без него или цикл с внутренним циклом while.^[2] Как правило, они служат для уменьшения общего длина пути инструкции требуется для завершения программы и / или уменьшения общего использования памяти во время процесса. С другой стороны, платформенно-зависимые методы включают планирование инструкций, параллелизм на уровне инструкций, параллелизм на уровне данных, методы оптимизации кэша (т.е. параметры, которые различаются для разных платформ) и оптимальное планирование выполнения инструкций могут отличаться даже на разных процессорах одной и той же архитектуры.

Снижение силы

Вычислительные задачи могут выполняться несколькими способами с разной эффективностью. Более эффективная версия с эквивалентной функциональностью известна как снижение силы. Например, рассмотрим следующие C фрагмент кода, целью которого является получение суммы всех целых чисел от 1 до N:

int я, сумма = 0;за (я = 1; я <= N; ++я) {  сумма += я;}printf("сумма:% d п", сумма);

Этот код может (при условии, что нет арифметическое переполнение) можно переписать с использованием математической формулы, например:

int сумма = N * (1 + N) / 2;printf("сумма:% d п", сумма);

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

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

Компромиссы

Однако в некоторых случаях оптимизация полагается на использование более сложных алгоритмов, использование «особых случаев» и специальных «уловок» и выполнение сложных компромиссов. "Полностью оптимизированная" программа может быть более сложной для понимания и, следовательно, может содержать больше недостатки чем неоптимизированные версии. Помимо устранения очевидных антипаттернов, некоторые оптимизации на уровне кода снижают ремонтопригодность.

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

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

Узкие места

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

В информатике потребление ресурсов часто определяется формой сила закона распространение, и Принцип Парето можно применить к оптимизации ресурсов, заметив, что 80% ресурсов обычно используются 20% операций.^[3] В разработке программного обеспечения часто бывает лучшим приближением, что 90% времени выполнения компьютерной программы тратится на выполнение 10% кода (в этом контексте известный как закон 90/10).

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

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

Когда оптимизировать

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

Дональд Кнут сделал следующие два заявления по оптимизации:

«Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол. Однако мы не должны упускать наши возможности в этих критических 3%».^[5]

(Он также приписал цитату Тони Хоар несколько лет спустя^[6] хотя это могло быть ошибкой, поскольку Хоар заявляет, что не придумал эту фразу.^[7])

«В общепринятых инженерных дисциплинах легко достижимое улучшение на 12% никогда не считается маргинальным, и я считаю, что такая же точка зрения должна преобладать в разработке программного обеспечения»^[5]

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

Решая, нужно ли оптимизировать конкретную часть программы, Закон Амдала всегда следует учитывать: влияние на программу в целом во многом зависит от того, сколько времени фактически затрачено на эту конкретную часть, что не всегда ясно, если посмотреть на код без анализ производительности.

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

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

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

Макросы

Оптимизация при разработке кода с использованием макросы принимает разные формы на разных языках.

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

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

Лисп возник этот стиль макроса,^{[нужна цитата]} и такие макросы часто называют «Lisp-подобными макросами». Подобного эффекта можно добиться, используя метапрограммирование шаблона в C ++.

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

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

Автоматическая и ручная оптимизация

Смотрите также Категория: Оптимизация компилятора

Оптимизация может быть автоматизирована компиляторами или выполнена программистами. Прибыль обычно ограничена для локальной оптимизации и больше для глобальной оптимизации. Обычно самая эффективная оптимизация - это поиск лучшего алгоритм.

Оптимизацией всей системы обычно занимаются программисты, потому что это слишком сложно для автоматических оптимизаторов. В этой ситуации программисты или системные администраторы явно изменяют код, чтобы система в целом работала лучше. Хотя он может повысить эффективность, он намного дороже, чем автоматическая оптимизация. Поскольку многие параметры влияют на производительность программы, пространство для оптимизации программы велико. Метаэвристика и машинное обучение используются для решения сложных задач оптимизации программ.^[8]

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

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

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

Узкие места в производительности могут быть связаны с языковыми ограничениями, а не с алгоритмами или структурами данных, используемыми в программе. Иногда важная часть программы может быть переписана на другом языке. язык программирования это дает более прямой доступ к базовой машине. Например, это обычное дело для очень высокий уровень языки как Python иметь модули, написанные на C для большей скорости. Программы, уже написанные на C, могут иметь модули, написанные на сборка. Программы, написанные на D можно использовать встроенный ассемблер.

Переписывание разделов "окупается" в этих условиях из-за общего "практическое правило" известный как 90/10 закон, в котором говорится, что 90% времени тратится на 10% кода и только 10% времени на оставшиеся 90% кода. Таким образом, интеллектуальные усилия по оптимизации лишь небольшой части программы могут иметь огромное влияние на общую скорость - если удастся найти правильную часть (части).

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

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

Сегодня автоматическая оптимизация почти исключительно ограничивается оптимизация компилятора. Однако, поскольку оптимизация компилятора обычно ограничивается фиксированным набором довольно общих оптимизаций, существует значительный спрос на оптимизаторы, которые могут принимать описания проблем и оптимизаций для конкретных языков, что позволяет инженеру определять индивидуальные оптимизации. Инструменты, которые принимают описания оптимизаций, называются преобразование программы систем и начинают применяться в реальных программных системах, таких как C ++.

Некоторые языки высокого уровня (Эйфель, Эстерель) оптимизируют свои программы, используя промежуточный язык.

Грид-вычисления или же распределенных вычислений направлена ​​на оптимизацию всей системы, перемещая задачи с компьютеров с высокой нагрузкой на компьютеры с простоями.

Время, затраченное на оптимизацию

Иногда время, затрачиваемое на оптимизацию, может быть проблемой.

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

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

В частности, для своевременные компиляторы исполнение время выполнения Компонент компиляции, выполняемый вместе со своим целевым кодом, является ключом к повышению общей скорости выполнения.

Рекомендации

внешняя ссылка

В Викиучебнике есть книга на следующие темы: Оптимизация кода для скорости

• Как написать быстрый числовой код: небольшое введение
• «Что должен знать каждый программист о памяти» Ульрих Дреппер - объясняет структуру современных подсистем памяти и предлагает, как их эффективно использовать
• "Анализ и оптимизация многоядерной производительности Linux в двух словах", слайды презентации Филиппа Муччи
• Оптимизация программирования от Пола Хси
• Написание эффективных программ («Правила Бентли») к Джон Бентли
• «Антипаттерны производительности» Барт Смолдерс