На этой странице обсуждения обсуждаются улучшения в статье об оптимизации программы . Это не форум для общего обсуждения темы статьи. |
Политика статьи
|
Найти источники: Google ( книги · новости · газеты · ученый · бесплатные изображения · WP рефов ) · FENS · JSTOR · NYT · TWL |
WikiProject Информатика | (Номинальный B-класс, высокая важность) |
---|---|
WikiProject Программное обеспечение / Компьютеры | (Номинальный B-класс) |
---|---|
Список дел по оптимизации программы : | |||
---|---|---|---|
|
Оценка
Я сделал оценку очень быстро, у статьи все еще есть некоторые проблемы. Например, мантра о «преждевременной оптимизации» добавлялась снова и снова без глобального обзора, поэтому для исправления этой статьи требуется глобальный рестайлинг. - Blaisorblade ( разговор ) 12:02, 7 января 2009 г. (UTC)
Перенаправление: оптимизация программного обеспечения
«Оптимизация программного обеспечения» перенаправляется сюда. В Великобритании это будет написано «Оптимизация программного обеспечения», которая в настоящее время не выполняет перенаправление сюда. Я не знаю, как это сделать, но если бы у нас тоже было это перенаправление, это было бы очень удобно, поскольку я продолжаю заходить на страницу поиска, задаваясь вопросом, что я сделал не так. 152.78.162.177 ( разговорное ) 14:39, 24 октября 2011 (UTC)
- Отправили запрос на этот 81.174.243.233 ( разговор ) 23:36, 17 ноября 2011 (UTC)
- Заявка принята. Этот вопрос закрыт. 81.174.243.233 ( разговорное ) 01:32, 18 ноября 2011 (UTC)
Балансировки нагрузки
Я знаю, вы можете сказать, что балансировка нагрузки - это настройка производительности, а не оптимизация, но, скорее всего, можно сказать, что «оптимизируйте всю систему путем балансировки нагрузки». - Таку
Об этом дополнении
- Обычно оптимизатор не изменяет фактический код, но создает код в то же время, когда компиляторы автоматически создают целевой код. Другими словами, избыточность или любой вид неэффективного кода в исходной программе остаются неизменными с оптимизаторами. Чтобы получить эффективный код без оптимизации, нужно оптимизировать код вручную. Однако, поскольку в большинстве современных компиляторов есть по крайней мере простые оптимизаторы, ручная оптимизация, которую может выполнить оптимизатор, обычно не требуется.
Я знаю, что для программистов это звучит ужасно излишне. Но я обнаружил, что часто люди, не знающие о компиляторах, предполагают, что оптимизаторы на самом деле скрывают код, написанный человеком, в более эффективный и эффективный код. И, конечно же, мы знаем, чего на самом деле не происходит. At18, извините, но я думаю, что ваша ревизия упускает этот момент. Я попробую еще раз. Посмотрите и при необходимости исправьте. - Таку 22:44, 14 мая 2003 г. (UTC)
- Привет, я нашел ваш абзац немного запутанным и заменил его более короткой версией. Вы, конечно, можете попытаться немного расширить его, чтобы лучше изложить свою точку зрения. At18, 08:13, 15 мая 2003 г. (UTC)
Слишком большой
Я думаю, что в этой статье делается попытка обсудить слишком много отдельных тем одновременно, и ее следует разделить на разные статьи, в которых обсуждаются оптимизации компилятора, ручная оптимизация людьми и настройка производительности больших систем с такими вещами, как балансировка нагрузки. Они могут связывать все, что захотят, но, на мой взгляд, эта статья недостаточно целенаправленна. Деррик Кутзи, 15:39, 15 ноября 2003 г. (UTC)
- Да, я согласен. Раньше было несколько статей, связанных с оптимизацией, потому что они пересекались. Я думал о разделении, но не знал, какие организации должны быть хорошими. Да, я думаю, что по крайней мере оптимизацию компилятора можно разделить. - Таку 15:51, 15 ноября 2003 г. (UTC)
Вспомните другие варианты использования оптимизации в информатике. Я написал программы для оптимизации эффективности маршрутизации судов навалочных грузов и выполнил эскизный проект системы для оптимизации системы транспортировки сырой нефти Национальной нефтяной компании Кувейта, и есть постоянная проблема оптимизации коммивояжера (которую несколько репрезентативны). Эта статья больше посвящена оптимизации кода и компилятора, чем всему спектру оптимизации в информатике. Я думаю, что Деррик сделал хорошее замечание, и что эта статья должна охватывать общие концепции в поверхностном обзоре, а затем давать ссылки на подробные статьи по конкретным методам в каждой области. JamesDay 12:34, 17 ноя 2003 (UTC)
- Хотя я согласен с тем, что в статье есть проблемы, извините, но я не согласен с вами, и я процитирую значения статьи, чтобы объяснить, почему. «Алгоритмы для решения задач оптимизации см. В разделе Оптимизация (математика) ». Устранение неоднозначности можно уточнить, но на самом деле вы говорите о задачах оптимизации, решаемых с помощью компьютерных программ, в то время как эта статья посвящена оптимизации производительности самих компьютерных программ. Чтобы избежать путаницы, переименование статьи в оптимизацию производительности может оказаться полезным. Я не согласен с деструктивным расколом, следует оставить общую статью, чтобы представить общую тему, и, возможно, перенести больше материала в другое место. Это обсуждение довольно старое! - Blaisorblade ( разговор ) 12:06, 7 января 2009 г. (UTC)
- Я согласен с этим. Есть какие-нибудь практические предложения относительно организации этой статьи? - Таку 19:13, 17 ноября 2003 г. (UTC)
- Я думаю, что статья должна быть разумно объединена с « Алгоритмической эффективностью», но должна быть «всеобъемлющей», чтобы сохранить все соответствующие вопросы в одном месте, что в значительной степени ускользнуло от внимания из-за разрозненных статей, которые все немного отличаются от не нейтральной точки зрения. Я попытался связать множество тем, но действительно требуется последовательный и логичный подход. Я считаю, что существующая статья об алгоритмической эффективности является хорошей отправной точкой для слияния любых текущих опущенных тем, которые появляются в других статьях. Один редактор прокомментировал мои добавления о том, что хороший выбор базы данных и определений данных очень важен на уровне дизайна, потому что он утверждал, что «большинство программ не используют базы данных» - полное невежество здесь просто невероятно! —Предыдущий комментарий без подписи, добавленный 81.129.233.212 ( обсуждение ) 16:29, 17 сентября 2008 г. (UTC)
Преждевременная оптимизация
«Преждевременная оптимизация» перенаправляется на эту страницу - я не думаю, что это должно быть. Преждевременная оптимизация - это тонкая проблема, которая не очевидна для новичка. Вот почему Дональд Кнут решил выделить его. Я хотел бы видеть некоторые практические правила или красные флажки, которые сигнализируют о преждевременности оптимизации. Что-то вроде того, когда кто-то говорит: «Это улучшит производительность вдвое, и мы сможем легко справиться с небольшим повышенным риском», или, когда проект близится к завершению, возникает безумная спешка, чтобы реализовать еще несколько улучшений производительности перед выпуском.
- На мой взгляд (но это только мое!), Вопрос о том, является ли оптимизация преждевременной, по сути, является вопросом опыта и личного выбора, и, следовательно, целый список того, какие виды оптимизаций являются преждевременными, действительно трудно установить, по крайней мере, в энциклопедии. Возможно, вам будет интересна Викибук по этой теме, или вы можете посмотреть библиографию этой статьи.
- Король Майк 15:03, 29 января 2006 г. (UTC)
- Все оптимизации являются преждевременными, если вы не _измерили_, что система работает слишком медленно. И нельзя измерить то, что еще не построено. Пропавший гоблин 16:34, 29 января 2006 г. (UTC)
- Точно. Грицко 04:15, 16 июня 2007 г. (UTC)
- Я категорически не согласен с этим комментарием. Может случиться так, что многие программисты, работающие над разными видами программ (особенно с настройками больших проектов), совершенно не знают, куда направляются их машинные ресурсы, но это вряд ли применимо ко всему, что можно запрограммировать. В частности, чем ниже уровень кода и чем больше программист знаком с базовой архитектурой, тем лучше будут понятны его характеристики производительности. Также неясно, что именно означает «профилирование». Я часто нахожу гораздо более полезным написать специализированные профилировщики, соответствующие характеру программы, чем просто полагаться на счетчик вызовов функций, но именно это люди обычно имеют в виду, когда упоминают профилирование. Для кода, который должен быть высокопроизводительным, вызовы функций могут полностью прерываться, и вы не получите информацию, которая почти так точно настроена, как вам нужно.
- Я считаю, что противоположность преждевременной оптимизации (слишком позднее ожидание для оптимизации) может быть столь же разрушительной, поскольку чем более зрелым является дизайн программы, тем менее приспособляемым она будет к основному пересмотру. Важно разрабатывать, программировать и постепенно пересматривать с учетом конкретных целей производительности и одновременно поддерживать чистый и элегантный дизайн, а не просто игнорировать производительность и верить, что вы сможете оптимизировать ее позже. Практика оптимизации в значительной степени зависит от понимания использования ресурсов с самого начала, поэтому в этом смысле действительно «преждевременная оптимизация» вряд ли вообще может считаться оптимизацией - обычно это просто применение нескольких тривиальных преобразований, которым научили пользователя, и скорее всего, показывает, что пользователь не может эффективно оптимизировать с самого начала. Опытный программист-оптимизатор будет хорошо разбираться как в базовой архитектуре (машина, библиотеки, ОС), так и в имеющихся инструментах (компилятор). Даже результаты профилировщика просто дают вам широкое пространство для начала и сбора некоторых динамических данных (которые вы можете сделать, просто понимая проблему); если вы не понимаете, куда идут ресурсы, вы не сможете его оптимизировать.
- Интересно, что хотя преждевременные оптимизации (которые я считаю псевдооптимизациями) могут нанести ущерб ясности и функциональности кода, настоящая оптимизация часто улучшает эти аспекты, делая код более простым и кратким. Также интересно огромное количество оптимизаций, которые сам Кнут дал в своих книгах. Я вижу, что мантра «корень всего зла» проповедуется так интенсивно без каких-либо дополнительных объяснений (что-то вроде огня и серы, когда формулировка и авторство сами по себе имеют такой вес, что такое объяснение считается излишним), что я абсолютно уверен что это увековечило отношение к ленивому программированию, которое привело к созданию программного обеспечения с невысокой производительностью. Опыт наводит меня на мысль, что часто люди, использующие эту фразу (во многом в отличие от Кнута), неспособны самостоятельно выполнить серьезную оптимизацию программы, с профилировщиками или без них. Exophase ( разговор ) 19:10, 8 февраля 2008 (UTC)
- Ваш последний абзац очень важен. Хотя кто-то может цитировать Кнута в защиту неаккуратного кодирования или ужасно медленного дизайна, это ИМХО неверное цитирование, и я бы проигнорировал это. Цитата должна применяться только к оптимизациям, которые затрудняют удобочитаемость / ремонтопригодность. Однако даже создание правильного дизайна требует времени, а иногда оптимизация дизайна не позволяет решить правильную проблему.
- Кроме того, ваши рассуждения, похоже, подразумевают, что профилирование производительности может понадобиться только не очень компетентному программисту. Это не правда. Очевидно, что у хорошего программиста есть некоторые подсказки относительно того, на что тратится время, но они часто ошибаются. На самом деле, я слышал мантру Кнута только от очень хороших программистов, например, в сообществе разработчиков Linux или в сообществе Google V8. - Blaisorblade ( разговор ) 00:12, 4 января 2009 г. (UTC)
- Согласен 100% 81.129.233.212 ( обсуждение ) 16:32, 17 сентябрь 2008 г.
Я согласен с Exophase на 100%. Я долгое время участвовал в разработке самодельного Snes, и определенно есть много высокомерных придурков, которые используют эту фразу как оправдание небрежному ужасному коду. По этой причине у Snes всегда была плохая репутация из-за медленного процессора. Они жалуются, что так долго оптимизируют готовый код и не видят значительного увеличения скорости. Я всегда советую им с самого начала программировать свой код последовательно и эффективно, чтобы им не приходилось беспокоиться об этом позже, но они никогда не принимают мой совет и неправильно цитируют фразу «преждевременная оптимизация - корень всего зла» и продолжают писать небрежный медленный код, думая, что они могут исправить все свои проблемы в конце. (УНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ)
Ссылка 'искусство программирования'
Я не знаю точно, какие части статьи вдохновлены цитируемым источником «искусство программирования». Я знаю одну книгу с таким названием, но она не посвящена оптимизации. Вместо этого, поскольку Д.Е. Кнут цитируется несколько раз в этой статье, настоящим источником может быть его книга «Искусство компьютерного программирования». Я ошибся ?
Король Майк
- Сделано Исправлено кем-то другим. - Blaisorblade ( разговор ) 01:12, 4 января 2009 г. (UTC)
Оптимизация слияния из цикла
Ну это классика, не правда ли? (независимо от того, слишком длинная эта статья). Ripper234 20:35, 2 апреля 2006 г. (UTC)
- Статья по оптимизации цикла выглядит хорошо сама по себе, и, поскольку мы пытаемся сократить эту статью, я бы рекомендовал не объединять их. CRGreathouse 23:38, 19 июля 2006 г. (UTC)
- Я против объединения обеих статей, возможно, вы ищете более конкретную, например оптимизацию компилятора . Фактически, я бы предложил удалить статью об оптимизации цикла или объединить ее с оптимизацией компилятора (которая, похоже, содержит первую статью ).
- Готово Объединение уже было удалено кем-то другим. - Blaisorblade ( разговор ) 01:13, 4 января 2009 г. (UTC)
Противоречие
Улучшение около 20% кода часто отвечает за 80% результатов, что противоречит 90% времени, которое тратится на 10% кода, и только 10% времени в оставшихся 90% кода Sjord 17:59 , 14 апреля 2006 г. (UTC)
- Строго говоря, я не думаю, что они говорят об одном и том же - один о написании кода, а другой о его переписывании. Тем не менее, я был бы счастлив, если бы оба были удалены, поскольку они по сути не поддаются проверке. CRGreathouse 23:38, 19 июля 2006 г. (UTC)
- Поскольку утверждения все еще существуют, даже если они были прояснены, я отвечу, сказав, что это хорошо известное практическое правило среди программистов. Если кто-то хочет оспорить это, поищите литературу по информатике об оптимизации или добавьте к ней [ необходима цитата ] . О кажущемся противоречии, правило излагается с разными ставками (80-20, 90-10), потому что это не точные ставки. Я думаю, однако, что первое утверждение было неправильно выведено из того, что «80% времени тратится на 20% кода» или что-то в этом роде. Я говорю «неправильно выведено», потому что здесь нельзя скопировать-n-вставить соотношения, например, потому что оставшийся исходный код вообще не должен быть оптимизирован. - Blaisorblade ( разговор ) 22:35, 3 января 2009 г. (UTC)
Язык очень высокого уровня
в статье говорится, что python - это «язык очень высокого уровня». Я бы сказал, что языки очень высокого уровня - это Domain-specific_programming_languages (DSL). ИМХО Python - это просто язык высокого уровня и это определенно не DSL!
- Ридель 21:57, 19 июля 2006 г. (UTC)
Энергоэффективность
В этой статье также должны быть рассмотрены аппаратные и энергетические аспекты эффективности и оптимизации. Но в настоящее время он вообще не обращается к ним и вообще не имеет ссылок на любую подобную информацию! - 69.87.202.60 12:05, 17 мая 2007 г. (UTC)
- Да, должно. Пожалуйста, добавьте их. Дерек Фарн 12:31, 17 мая 2007 г. (UTC)
Следует ли удалить ссылку на «Призыв к экономному программному обеспечению»?
Связь
относится к статье, для чтения которой требуется платная подписка. WP: Правила EL гласят: «6. Ссылки на сайты, требующие оплаты или регистрации для просмотра соответствующего содержания». следует избегать вообще. Если его размещает IEEE, я ожидаю, что это будет классическая статья. Тем не менее, он недоступен без оплаты. Можно ли удалить ссылку? С уважением, - Камакан 03:33, 26 июля 2007 г. (UTC)
- Можно ли вместо этого дать ссылку на что-то вроде: http://cr.yp.to/bib/1995/wirth.pdf ? Кроме того, текущая ссылка, по крайней мере, указывает на аннотацию, это не так уж и плохо .... - DFRussia 07:57, 18 августа 2007 г. (UTC)
Система против программы против кода
Мне кажется, что эта тема начинается правильно - речь идет об оптимизации системы, а затем переходит к разговору об оптимизации фрагментов кода. Но это два разных зверя. Комментарии о преждевременной оптимизации (Кнут и другие) сосредоточены на оптимизации фрагментов кода. Но учтите - многие из этих цитат очень старые - лет 30 или около того. И они применимы к этой области (оптимизация кода), но не к оптимизации системы, которая в целом охватывает всю инфраструктуру.
Как вы думаете? Вс , вс , вторник, 17:58, 13 ноября 2007 г. (UTC)
интерпретируемые языки
Раздел об интерпретируемых языках - чушь собачья. Интерпретаторы обычно работают в три этапа: анализ источника на серию токенов, анализ токенов в синтаксическое дерево и затем интерпретация синтаксического дерева. Безусловно, наиболее затратным с точки зрения вычислений является последняя фаза, потому что именно там код фактически выполняется. Удаление лишних пробелов и комментариев влияет только на первую фазу (лексический анализатор), которая и так проходит очень быстро.
В этом разделе действительно говорится об оптимизации размера по сети. Это не имеет ничего общего с интерпретируемыми языками. Вы видите это для любой формы данных. Для любых данных, будь то исходный код, исполняемые файлы или простые носители, лучше иметь меньший размер, чтобы на их передачу по сети требовалось меньше времени.
В заключение я предлагаю удалить этот раздел и, возможно, заменить его очевидным заявлением «данные должны быть оптимизированы по размеру для ускорения передачи по сети».
- 72.177.62.3 ( разговорное ) 22:58, 11 декабря 2007 г. (UTC)
Макросы
Раздел макросов мне кажется неточным. Во-первых, утверждается, что макросы препроцессора C в основном ограничены выполнением той же функции, что и встроенные. Я видел этот аргумент раньше, который заставил людей в значительной степени осудить макросы, поскольку встроенные более безопасны и практичны. На самом деле макросы препроцессора C могут выполнять многие из тех же функций, что и макросы типа Lisp или шаблоны C ++. Это потому, что они не просто расширяются до текста, ограниченного одним проходом, но также рекурсивно расширяют все расширения. Это позволяет передавать имена макросов (или параметрические части имен макросов) в качестве параметров макроса, и хотя расширение является либо очень широким и конкретным, либо очень общим (в отличие от чего-то смешанного, например, что позволяет специализация шаблона), оно может быть иерархически организовано так, чтобы минимизировать количество избыточных макросов, необходимых для специализации. Я видел, как мало кто действительно использует макросы CPP таким образом, но это можно сделать, и это довольно мощно (и я регулярно программирую с помощью этой техники).
Во-вторых, я не понимаю, какие утверждения делают, что «скомпилированный код» заменяется в Lisp-подобных макросистемах. Скомпилированный код не изменяется и не вставляется. Макрорасширение - это такое же текстовое расширение, как и стиль CPP, оно просто имеет больше возможностей для сопоставления с образцом, гигиены, саморекурсии, специализации и т. Д. Однако это, безусловно, гораздо более мощная система.
Я был бы признателен, если бы некоторые другие, у которых есть опыт работы с этими темами, могли внести свой вклад. Я считаю, что весь этот раздел следует переписать, хотя он может и не входить в этот узел с самого начала.
Exophase ( разговор ) 19:53, 8 февраля 2008 (UTC)
На мой взгляд, этот раздел не принадлежит вообще. Макросы (будь то C ++ или Lisp) предлагают некоторую эффективность за счет синтаксического анализа и времени компиляции, но такая эффективность редко применяется к концепции оптимизации, обсуждаемой в основной статье. Предлагаю полностью удалить этот раздел. 97.117.232.119 ( разговор ) 03:55, 27 сентября 2008 (UTC) Фараз Бабар.
Я согласен с тем, что макросы - это гораздо более широкая тема, чем оптимизация. В частности, я считаю макросы «автоматическим программистом для бедняков», и при разумном использовании они могут превратить ваш исходный код во что-то, что приближается к предметно-ориентированному языку. Я полагаю, это поднимет у некоторых людей мех. Майк Данлавей ( разговор ) 22:06, 7 ноября 2008 (UTC)
- Я регулярно использую макросы C, которые нельзя заменить встроенными, но это не имеет никакого значения для этой статьи (даже если вы можете использовать их для некоторых оптимизаций, я не вижу в этом заметного паттерна). Я действительно переписал этот раздел - я знал и макросы C, и макросы Scheme, и провел некоторые исследования по макросам Lisp. Я согласен с использованием доменных языков через макросы (никогда не использовал их таким образом, но совершенно очевидно, что это возможно - в конце концов, даже библиотеки можно описать как DSL). Что касается «подстановки скомпилированного кода» в системах Lisp, надеюсь, я прояснил этот вопрос в новом тексте. - Blaisorblade ( разговор ) 11:56, 7 января 2009 г. (UTC)
Я согласен с Фаразом Бабаром в том, что раздел о макросах не имеет прямого отношения к оптимизации или, по крайней мере, определенно не требует такого обширного освещения. Это означает, что макросы сами по себе являются методом оптимизации, а это не так - можно снизить производительность с помощью макроса на языке C путем многократного вычисления выражений аргументов. Он также неправильно помещен в подраздел «Когда оптимизировать» - предшествующий неподписанный комментарий, добавленный 217.40.148.115 ( обсуждение ) 10:05, 13 марта 2009 г. (UTC)
- Я тоже согласен. Вероятно, он должен уйти, если будет консенсус. На данный момент я исправил, чтобы это не было подразделом «Когда оптимизировать»; спасибо, что указали на это. Шриватса ( разговор ) 13:47, 13 марта 2009 (UTC)
- Я также согласен с тем, что использование макросов представляет собой чисто замену кода и, следовательно, может оптимизировать время разработки программного обеспечения, но не улучшает производительность, о которой идет речь в этой статье. - Предыдущий беззнаковый комментарий добавлен 141.228.106.150 ( обсуждение ) 09:51, 11 октября 2012 г. (UTC)
Оспаривание приговора (о макросах)
«В некоторых процедурных языках, таких как C и C ++ , макросы реализованы с использованием текстовой подстановки, и поэтому их преимущество в основном ограничивается избежанием накладных расходов на вызов функций».
Любой, кто прочитает статью о встраивании в Википедии, знает, что удаление накладных расходов на вызов функции - это наименьший эффект, который имеет встраивание кода. Постоянное сворачивание и удаление мертвого кода имеют гораздо большее влияние. Я не собираюсь менять это сам, потому что ничего не знаю о языках функционального программирования. Themania ( разговор ) 10:19, 5 апреля 2008 (UTC)
- Готово. Я изменил абзац, старый текст не имел особого смысла - я предполагаю, что он был написан программистом на Лиспе с ограниченными знаниями C / C ++. Однако некоторые детали могут нуждаться в исправлении. - Blaisorblade ( разговор ) 10:02, 5 января 2009 г. (UTC)
Открытие
Третий абзац открытия:
- Оптимизация может происходить на нескольких уровнях. На самом высоком уровне дизайн может быть оптимизирован для наилучшего использования доступных ресурсов. Реализация этого проекта выиграет от использования эффективных алгоритмов, а реализация этих алгоритмов выиграет от написания кода хорошего качества. Использование оптимизирующего компилятора обеспечивает оптимизацию исполняемой программы. На самом низком уровне можно полностью обойти компилятор и написать ассемблерный код напрямую. С современными оптимизирующими компиляторами и большей сложностью последних процессоров требуется большое мастерство для написания кода, который лучше, чем тот, который может сгенерировать компилятор, и немногим проектам нужно прибегать к этому окончательному шагу оптимизации. Хотя большой объем написанного сегодня кода по-прежнему скомпилирован для работы на наибольшем проценте машин. В результате программисты и компиляторы не всегда пользуются преимуществами более эффективных инструкций, предоставляемых новыми процессорами. Поскольку оптимизация часто основывается на использовании особых случаев и выполнении сложных компромиссов, полностью оптимизированная программа обычно труднее для понимания людьми, поэтому имеет тенденцию содержать больше ошибок, чем неоптимизированные версии; хотя, как правило, это справедливо для тех, кто плохо знаком с языком программирования, на котором он был написан.
представляет собой мешанину из нескольких идей; Я попытался отредактировать его, но не смог найти хороший способ справиться с этим. Какие-либо предложения?
Я вижу следующие моменты:
- Есть разные уровни оптимизации
- Ручное кодирование редко превосходит компиляторы (пояснение: не мое утверждение)
- Код часто компилируется без машинно-зависимых флагов
- Оптимизированный код более хрупкий, чем неоптимизированный.
Что из этого нужно охватить в открытии, и все ли они должны быть в этом абзаце вместе?
CRGreathouse ( t | c ) 04:33, 11 февраля 2008 г. (UTC)
- Я думаю, что второй пункт, в частности, не должен быть во вступлении, а должен иметь отдельный раздел, потому что он заслуживает некоторой проработки. Во-первых, я думаю, что то, что вы сказали, преувеличено (и не отражает того, что было сказано в исходном абзаце) - для некоторых платформ, таких как ARM (по крайней мере, версии, широко доступные прямо сейчас), где GCC используется преимущественно ручное кодирование, может превзойти это на регулярной основе. «Редко необходимый» может быть подтвержден общим консенсусом, но утверждение, что кодируемый вручную ASM редко может превзойти компилятор, должно быть подкреплено эмпирическими доказательствами, если таковые существуют.
- Exophase ( разговор ) 18:04, 11 февраля 2008 (UTC)
Я полностью согласен с Exophase, ручное кодирование может извлечь выгоду из опыта и хорошей практики намного больше, чем может быть способен компилятор. Компилятор не может делать то, что, например, умеет грамотно спроектированный JIT -компилятор. Я знаю, потому что большинство моих программ разрабатывались мною таким образом на протяжении 40 с лишним лет, с тех пор как я осознал преимущества примерно в 1968 году. Мой код также был чрезвычайно надежным, гораздо более надежным, чем большинство других скомпилированных или иным образом, и обычно более четким, короче и построена на строках таблицы решений, четко показывающих каждый тип решения и действия. Я по-прежнему считаю, что Assembler - это самый простой язык для написания хорошего кода, гораздо более эффективный, чем C, и, если он правильно задокументирован, на самом деле легче поддерживать. Это миф, что Ассемблер не может быть произведен экономично и с использованием макросов может быть на самом деле короче, чем эквивалентный материал HLL. См. [ [1] ], где приведен пример таблицы переходов, где таблица переходов в стиле SWITCH / case реализована примерно в 4 машинных инструкциях без какого-либо сравнения! 81.129.233.212 ( разговорное ) 14:34, 17 сентября 2008 (UTC)
Оптимизация ассемблера требует "большого мастерства"
«С современными оптимизирующими компиляторами и большей сложностью последних процессоров требуется большое мастерство для написания кода, который лучше, чем тот, который может сгенерировать компилятор, и немногие проекты нуждаются в этом окончательном шаге оптимизации. Хотя большой объем кода, написанный сегодня, является по-прежнему скомпилирован для работы на наибольшем проценте машин. В результате программисты и компиляторы не всегда пользуются преимуществами более эффективных инструкций, предоставляемых более новыми процессорами ».
Я должен не согласиться, в случае потоковых инструкций и общих оптимизаций ассемблера единственные требуемые навыки - это уметь писать ассемблер и знать об их существовании. Очень легко сделать даже компилятор MS C ++ с помощью некоторого asm ... мой первый набег на программирование на ассемблере был именно для этой цели и был настолько легким, что мой ужасно неэффективный встроенный ассемблер был быстрее. Даже такие простые вещи, как memcpy и memset, упакованные в последние библиотеки времени выполнения для MSVC ++, можно легко оптимизировать, используя развернутые циклы и инструкции невременного копирования ... Конечно, нет ничего более умелого, чем просто использовать предоставленные инструкции, как они были задуманы. использовал.
Другой классический пример: вам нужно указать набор инструкций в компиляторе MSVC ++, тогда как легко (хотя и требует много времени) написать код, который работает на всех процессорах Intel, используя инструкции SSE / SSE2 и т. Д. В зависимости от ситуации.
Я думаю, что эти технологии все еще относительно новы для компилятора, и поэтому поддержка еще не является полной или мощной. Я уверен, что компиляторы и библиотеки наверстают упущенное, но всегда будут доступны новые технологии, которые позволят людям, знающим их, превзойти компиляторы ...
Конечно, это применимо только к небольшому набору оптимизаций, это, конечно, не во всех случаях легко ... но во многих случаях, когда вы хотите это сделать, это так.
Я нахожу разочарование, что программирование на ассемблере помечено как «что-то сложное, что вам, вероятно, не нужно», хотя на самом деле это просто и полезно ... особенно когда у вас заканчиваются оптимизации ... вы даже можете обнаружить, что оптимизация memcpy или memset обеспечит значительный прирост (в программном рендерере треугольников размером ~ 512x512, используемом в Winamp AVS, прирост скорости от обнуления памяти с помощью ассемблера составил примерно 3-4 кадра в секунду, с 27 кадров в секунду до примерно 30 кадров в секунду).
Я собираюсь отредактировать это утверждение, чтобы убрать часть «великие навыки», это кажется неуместным, даже если я проигнорирую свои личные чувства по этому поводу ... «это чаще всего сложно» лучше, я-то ... - комментарий без подписи, добавленный 194.168.3.18 ( обсуждение ) 15:28, 25 марта 2008 г. (UTC)
упс ... не авторизован - Джерико ( обсуждение ) - Предыдущий неподписанный комментарий, добавленный 194.168.3.18 ( обсуждение ) 15:31, 25 марта 2008 г. (UTC)
- «Вы должны указать набор инструкций в компиляторе MSVC ++», очевидно, не считается программированием на ассемблере. Затем вы говорите, что можете превзойти «даже компилятор MS C ++» ... Я пользователь GCC, но единственный действительно хороший оптимизирующий компилятор, о котором я знаю, - это компилятор Intel ICC (но GCC по какой-то причине использовался некоторое время назад чтобы часто превосходить его по целочисленному программированию - надеюсь, они исправили ICC). Наконец, развертывание цикла не лишено недостатков, поэтому большинству пользователей следует просто полагаться на библиотеки (и иметь хорошие). Я удивлен, что компиляторы не могут с этим справиться. Текущий текст в любом случае в порядке, поэтому отметьте его как Готово . - Blaisorblade ( разговор ) 11:49, 7 января 2009 г. (UTC)
Абстрактные синтаксические деревья?
Возможно, я пропустил это в «незаполненных списках», представленных в конце этой статьи, но обсуждение оптимизаций на основе AST, кажется, бросается в глаза в его отсутствии. В информатике существуют и другие формы «оптимизации», которые не обязательно сосредоточены на переписывании и перекомпоновке кода; на ум приходит кеширование. SqlPac ( обсуждение ) 03:01, 19 сентября 2008 г. (UTC)
Параллельное программирование
Использование многоядерных процессоров, многопоточности и других методов одновременной обработки полностью исключено из этой статьи. (Я добавил ссылку в список). Но на самом деле в наше время это один из ключевых методов оптимизации программного обеспечения по времени. (Даже на одноядерном процессоре использование нескольких потоков часто будет быстрее, поскольку операционная система часто может более оптимально разделить время процессора). - Предыдущий беззнаковый комментарий добавлен 141.228.106.150 ( обсуждение ) 09:56, 11 октября 2012 г. (UTC)
Компромиссы
У меня есть комментарий к разделу "Компромиссы". Несомненно, существует оптимальная кривая компромисса между, например, временем и использованием памяти в алгоритме. Однако читателю следует дать понять, что очень немногие программы (в отличие от теоретических алгоритмов) действительно находятся на этой кривой. По моему опыту, многие программы можно улучшить как по времени, так и по памяти, и, таким образом, приблизить их к кривой. Майк Данлавей ( разговор ) 15:50, 8 ноября 2008 г. (UTC)
Эта статья переименована в оптимизацию программы
Об этом и говорится в 99% статьи. Попытка обобщить это на оптимизацию XXX в информатике, дефрагментацию диска , оптимизацию IP- маршрута (погуглите это, поскольку у нас, похоже, нет статьи) или даже различные формы оптимизации оборудования, например, оптимизация VLSI безнадежно широка. Pcap ping 18:11, 1 сентября 2009 г. (UTC)
Предлагаю изменить название на «улучшение кода». Термин «оптимизация» употребляется неправильно, поскольку он иногда используется в точном смысле в математике и теории информации. Когда мы пытаемся сделать код быстрее, мы редко можем сказать наверняка, что нет даже лучшего способа сделать то же самое. 188.126.200.132 ( разговор ) 04:34, 20 июля 2014 (UTC)
Когда (не) оптимизировать
Я помню цитату о следующем: Единственная подходящая оптимизация - это когда вы измерили скорость, а она слишком медленная (для каких бы целей она ни использовалась). Откуда эта цитата? Можно ли это встроить в эту страницу? Это кажется крайне актуальным.
Также учтите, что скорость компьютеров всегда увеличивается (см. Закон Мура), а способность людей понимать программный код со временем только уменьшается из-за различных факторов. Следовательно, мы не должны оптимизировать скорость компьютера, наше время лучше потратить на оптимизацию для человеческого понимания.
Цель оптимизации
Статья начинается с целей оптимизации.
До сих пор не хватает одной цели: удобочитаемости / ремонтопригодности.
Если вы сравните это с автомобилями: большинство людей настраивают свои машины, чтобы они были быстрее, но автомобили можно настроить так, чтобы они выглядели лучше или для большего удобства - предшествующий неподписанный комментарий, добавленный Геттли ( обсуждение • вклад ) 14:48, 9 января 2019 г. (UTC)