Программисты и люди компетентные в этом вопросе, давай обсудим такую тему: Нужна ли оптимизация программного кода? и если да, то в какой мере ее применять?
Я довольно много времени уделил олимпиадному программированию и теории эффективных алгоритмов, а также разработке прикладного програмного обеспечения, но чем дальше, тем глубже я сталкиваюсь с тем что оптимизация совсем не приветствуется при разработке "рядового" ПО. Неужели, деЙствительно, опт. кода должна отходить на задний план, а то и вообще за линию горизонта? Посмотрите как с развитием аккордности ресурсов "железа" возрастает тенденция к написанию совершенно (простите за грубость) бездарных программ в плане эффективности использования этих ресурсов. Чтобы было понятнее приведу несколько пар "аспект::мнение":
.]:. при разработке OpenSourse программ поступает предложение "не пиши ты так сложно! хрен разберешься в твоем коде" :: Здесь можно выявить две логики: 1- оптимизация не математическая, а программерская (те опирающаяся на языковую реализацию и выбор компилятора). В этом случае действительно бывают моменты, что не просто человек, выбравший другие технологии, а сам черт ногу сломит. Но так ведь OpenSourse расчитан на неоптимизированный код (с этой точки зрения), а вот при компиляции такого проекта уже можно и извращаться. 2- оптимизация самого алгоритма. хм, те людям людям тяжело напрячь мозги и разобраться в алгоритме с более сложной логикой? Простой пример: полный перебор - ну "не всегда он уместен";
.]:. разработка системного ПО :: вот здесь, на мой взгляд стоит выжать все ресурсы программерского интеллкта и переботать много инфы
.]:. А вот еще пример: создание сетевых приложений (прим. я думаю Тошик меня поймет) :: мало того, что задуматься о скорости и сжатии данных надо, так еще и о безопасности.
Простите если написал немного неоптимизированно в объеме, но все же помогите мне понять нужна ли в современное время прогресса оптимизация (я говорю сразу о трех оптимизационных направлениях: скорости, размера и "поедании" системных ресурсов, а так же о балансе всех их вместе взятых) или же достаточно довериться средам разработке (в том числе и компиляторам). Заранее признателен.
- ministr_two
- Случайно забежавший
- Сообщения: 4
- Зарегистрирован: Ср фев 08, 2006 6:22
- Откуда: г.Шахты
- Контактная информация:
Оптимизация?.. А это кто?
"640 KB должно быть достаточно для любого" (Билл Гейтс 1981)
ministr_two,
проблема в том, что разработка прикладного ПО чаще всего сводится к использованию приложением каких-либо уже готовых сервисов, будь то движок БД (чаще всего), библиотека сетевых протоколов или мультимедийный ввод/вывод.
Поэтому более/менее грамотно написаный код, в ущерб читабельности, "оптимизировать" не стоит. А написание менеджеров памяти далеко не все занимаются )), а вот там оптимизация кода нужна
проблема в том, что разработка прикладного ПО чаще всего сводится к использованию приложением каких-либо уже готовых сервисов, будь то движок БД (чаще всего), библиотека сетевых протоколов или мультимедийный ввод/вывод.
Поэтому более/менее грамотно написаный код, в ущерб читабельности, "оптимизировать" не стоит. А написание менеджеров памяти далеко не все занимаются )), а вот там оптимизация кода нужна
Люблю повеселиться, особенно пожрать,
Люблю и поработать, особенно поспать )
Люблю и поработать, особенно поспать )
- ministr_two
- Случайно забежавший
- Сообщения: 4
- Зарегистрирован: Ср фев 08, 2006 6:22
- Откуда: г.Шахты
- Контактная информация:
.:[. Это одна из сторон моего рассуждения. В том-то и дело, что многие сервисы в целом не оптимизированы, зачастую разработчики таких сервисов пытаются заработать авторитет не на производительности, а на многофункциональности, и соответственно уделяют минимум времени проблемам оптимизации. А программы, использующие данные сервисы, раздуваются до неимоверных размеров.
.:[. С другой сторны, один и тот же сервис предназначен для различных платформенных, аппаратных и т.д. реализаций. Грубо говоря, если разработчик, использующий тот или иной сервис, видит перед собой конкретную задачу должен сам избавляться от ненужных строк кода в этом сервисе (для этого необходимо четко представлять как он работает) и оптимизировать его под свои потребности, веть большинство из них идет в открытом коде, или с кучей настроек и "прикруток".
.:[. В противном наблюдается тенденция понижения качества программирования в целом. Программист, позволяющий себе выпускать неоптимизированную проукцию со временем "отупевает" (поймите меня правильно), а это влечет за собой торможение развития информационных технологий, появляются совершенно "некрасивые" идеи. Если вспомнить времена развития ИТ: разработчик, который заботится над совершенностью каждой строчки кода и алгоритма в целом постоянно совершает тренировку мозга, следовательно его идеи будут значительно совершенней, ведь успех это лишь 2% таланта и 98% упорства и кропотливого труда.
.:[. Если говорить о удобочитаемости кода, то стоит отметить принцип работы OpenSourse: разработчик пишет удобочитаемый код, а те, кто готовит дистрибутивы должны дорабатывать это код, и "совершать" над ним низкоуровневую оптимизацию (которая делает код совершенно неудобоваримым), а для масс - пожалуйста есть первоначальный код. те пишите, "математически" оптимизируйте, а затем уже выкладывайте его на всеобщее обозрение.
.:[. С другой сторны, один и тот же сервис предназначен для различных платформенных, аппаратных и т.д. реализаций. Грубо говоря, если разработчик, использующий тот или иной сервис, видит перед собой конкретную задачу должен сам избавляться от ненужных строк кода в этом сервисе (для этого необходимо четко представлять как он работает) и оптимизировать его под свои потребности, веть большинство из них идет в открытом коде, или с кучей настроек и "прикруток".
.:[. В противном наблюдается тенденция понижения качества программирования в целом. Программист, позволяющий себе выпускать неоптимизированную проукцию со временем "отупевает" (поймите меня правильно), а это влечет за собой торможение развития информационных технологий, появляются совершенно "некрасивые" идеи. Если вспомнить времена развития ИТ: разработчик, который заботится над совершенностью каждой строчки кода и алгоритма в целом постоянно совершает тренировку мозга, следовательно его идеи будут значительно совершенней, ведь успех это лишь 2% таланта и 98% упорства и кропотливого труда.
.:[. Если говорить о удобочитаемости кода, то стоит отметить принцип работы OpenSourse: разработчик пишет удобочитаемый код, а те, кто готовит дистрибутивы должны дорабатывать это код, и "совершать" над ним низкоуровневую оптимизацию (которая делает код совершенно неудобоваримым), а для масс - пожалуйста есть первоначальный код. те пишите, "математически" оптимизируйте, а затем уже выкладывайте его на всеобщее обозрение.
"640 KB должно быть достаточно для любого" (Билл Гейтс 1981)
ministr_two,
под "сервисом" я подразумеваю не самописную поделку, а готовый прект/библиотеку/драйвер, из которой лишних строк не выкинеш и всё там оптимизировано программерами куда большего уровня чем мой.
Посылаешь запрос движку дазы данных - он возвращает ответ.
Задача прикладного программиста - правильно составлять эти самые запросы.
А грамотный код оптимизировать не зачем.
под "сервисом" я подразумеваю не самописную поделку, а готовый прект/библиотеку/драйвер, из которой лишних строк не выкинеш и всё там оптимизировано программерами куда большего уровня чем мой.
Посылаешь запрос движку дазы данных - он возвращает ответ.
Задача прикладного программиста - правильно составлять эти самые запросы.
сейчас в низкоуровневой оптимизации почти нету смысла, встроеные оптимизаторы справляются с этим очень хорошо.сли говорить о удобочитаемости кода, то стоит отметить принцип работы OpenSourse: разработчик пишет удобочитаемый код, а те, кто готовит дистрибутивы должны дорабатывать это код, и "совершать" над ним низкоуровневую оптимизацию (которая делает код совершенно неудобоваримым), а для масс - пожалуйста есть первоначальный код. те пишите, "математически" оптимизируйте, а затем уже выкладывайте его на всеобщее обозрение.
А грамотный код оптимизировать не зачем.
Люблю повеселиться, особенно пожрать,
Люблю и поработать, особенно поспать )
Люблю и поработать, особенно поспать )
- ministr_two
- Случайно забежавший
- Сообщения: 4
- Зарегистрирован: Ср фев 08, 2006 6:22
- Откуда: г.Шахты
- Контактная информация:
Eraser, я еще раз повторюсь, что "сервисы" пишутся для обширной области применения, те. если это графическая библиотека, то там описаны индивидуальные свойства видеокарт, так же помимо этого - усредненные функции для большинства карт сразу, если это какой-нибудь сетевой компонент, то здесь собраны процедуры для работы со многими протоколами, итд. И в результате компиляции в бинарик попадают многие ненужные определения (это конкретный пример, без обобщения). Вот простой пример (первый, пришедший на ум): допустим мы разрабатываем простое приложение на ассемблере (пусть это необходимо) и совсем нет необходимости использовать 32х битную адрессацию, те. достаточно 16и битной. Я готов спорить, что большинство "современных программистов" будут лепить бызов 32х битных регистров, вот в этом самом месте никакие встроенные оптимизаторы не помогут, а достаточно всего лишь поменять вызовы и вставить директиву компилятора ( !важно - у всех компиляторов они "разные" (уже с обобщением) и это (хотя и не только) я подразумеваю под низкоуровневой оптимизацией) использовать 16 битный режим, тогда вскорость работы программы увеличится (в зависимости от количества вызовов) где-то на 20%. А если это какой-нить системный драйвер, и на 20% - это просто изумительно :cheesy:
Еще пример - Delphi, зачем писать программы среднего класса ( не огромные проекты - RTTI рулит) с использованием VCL? при отказе от этой технологии размер выходного бинарика упадет точно на 70-80% и скорость заметно вырастет. Это пример оптимизации технологии хоть и лажевый.
А теперь насчет asm-вставок, тоже на примере: ты пишешь игру, используешь стек, но твоя реализация стека например на STL, а что быстрее работает комманды проца pop and push или реализация на STL? Поправить код можно минимум часа за N, но зато результат ощутимый. Кстати, грамотного кода без оптимизации мало.
Еще пример - Delphi, зачем писать программы среднего класса ( не огромные проекты - RTTI рулит) с использованием VCL? при отказе от этой технологии размер выходного бинарика упадет точно на 70-80% и скорость заметно вырастет. Это пример оптимизации технологии хоть и лажевый.
А теперь насчет asm-вставок, тоже на примере: ты пишешь игру, используешь стек, но твоя реализация стека например на STL, а что быстрее работает комманды проца pop and push или реализация на STL? Поправить код можно минимум часа за N, но зато результат ощутимый. Кстати, грамотного кода без оптимизации мало.
"640 KB должно быть достаточно для любого" (Билл Гейтс 1981)
- ministr_two
- Случайно забежавший
- Сообщения: 4
- Зарегистрирован: Ср фев 08, 2006 6:22
- Откуда: г.Шахты
- Контактная информация:
Михаил Фленов www.vr-online.ru писал(а):Самое распространенное место работы, которое можно найти в любом городе – программист баз дынных. Такие программисты нужны везде, всегда и в любой, даже самой маленькой конторе. Только если контора маленькая, то там мучаются с разными 1С, Галактикой или Парусом, а солидные фирмы считают свои деньги и проблемы от таких пакетов, поэтому используют свои мозги и готовы платить хорошим программистам хорошие деньги.
"640 KB должно быть достаточно для любого" (Билл Гейтс 1981)
ministr_two,
OK.
OK.
именно так, есть стандартные системные библиотеки/интерфейсы GDI, GDI+, DirectDraw, Avalon наконец.те. если это графическая библиотека, то там описаны индивидуальные свойства видеокарт, так же помимо этого - усредненные функции для большинства карт сразу
и что в этом плохово? нехватает места на жётком диске или лишних 300 КБ скачать с инета сложно...?если это какой-нибудь сетевой компонент, то здесь собраны процедуры для работы со многими протоколами, итд. И в результате компиляции в бинарик попадают многие ненужные определения (это конкретный пример, без обобщения)
Извини за грубость, это бред ты написал. 32х разрядная адресация используется потому что все современные процессоры работают с 32 разрядными указателями, и меньше чем по 4 байта вообще не может физически считать/записать.Вот простой пример (первый, пришедший на ум): допустим мы разрабатываем простое приложение на ассемблере (пусть это необходимо) и совсем нет необходимости использовать 32х битную адрессацию, те. достаточно 16и битной. Я готов спорить, что большинство "современных программистов" будут лепить бызов 32х битных регистров, вот в этом самом месте никакие встроенные оптимизаторы не помогут, а достаточно всего лишь поменять вызовы и вставить директиву компилятора ( !важно - у всех компиляторов они "разные" (уже с обобщением) и это (хотя и не только) я подразумеваю под низкоуровневой оптимизацией) использовать 16 битный режим, тогда вскорость работы программы увеличится (в зависимости от количества вызовов) где-то на 20%. А если это какой-нить системный драйвер, и на 20% - это просто изумительно
размер exe действительно уменьшится, а вот на скорость почти не влияет. Практика - критерий истины. К тому же уже есть .NET - размер исп. файла мизерный.при отказе от этой технологии размер выходного бинарика упадет точно на 70-80% и скорость заметно вырастет.
т.к. я работаю на делфи, а там, как известно STL нету, и мне понадобится написать стек, то я организую его с пом. массива, т.е. TList и делов то..А теперь насчет asm-вставок, тоже на примере: ты пишешь игру, используешь стек, но твоя реализация стека например на STL, а что быстрее работает комманды проца pop and push или реализация на STL?
вцелом согласен с высказываением, но Флеонова не уважаю как автора книг, мож. он программист и хороший, но книги писать ему не надо.Самое распространенное место работы, которое можно найти в любом городе – программист баз дынных. Такие программисты нужны везде, всегда и в любой, даже самой маленькой конторе. Только если контора маленькая, то там мучаются с разными 1С, Галактикой или Парусом, а солидные фирмы считают свои деньги и проблемы от таких пакетов, поэтому используют свои мозги и готовы платить хорошим программистам хорошие деньги.
Люблю повеселиться, особенно пожрать,
Люблю и поработать, особенно поспать )
Люблю и поработать, особенно поспать )
- JokerR
- Новичок
- Сообщения: 86
- Зарегистрирован: Чт сен 15, 2005 1:03
- Откуда: Шахты
- Контактная информация:
Tony HoarePremature optimization is the root of all evil.
Первое правило оптимизации программ: не оптимизируйте.
Второе правило оптимизации программ (только для профессионалов!): всё-равно не оптимизируйте.
Прежде всего, программа должна быть работоспособной. Это главное что заботит пользователя. Редко (в некоторых областях программирования, для очень малого числа задач) степень оптимизированности (быстродействие, объём занимаемой памяти, итд) программы является определяющим фактором работоспособности. Тут несколько нужно прояснить, что я понимаю под работоспособной программой. Работоспособная программа это не та, которая сможет работать, а та, которая сможет работать удовлетворяя потребности пользователя.
Это была преамбула.
Амбула
Почему преждевременная оптимизация корень всех зол? На самом деле всё очень просто. Программу с хорошей архитектурой, легко расширяемую и понятную легко оптимизировть. Однако программа, в процессе написания которой ставка делается на оптимизацию - никогда не будет иметь хорошую архитектуру (её там вообще не будет), а понятность её будет стремится к нулю.
Ещё раз:
грамотная программа -> оптимизированная - легко.
оптимизированная программа -> грамотная - невыполнимо.
Даже там где оптимизация является критерием работоспособности программы, никто сразу не пишет программу так, чтобы она была оптимизированна по максимуму. Только после написания программы критические участки кода (а это зачастую очень малая часть кода, 10% и менее) оптимизируются до требуемого уровня. Даже в случае вынужденной оптимизации программ, лучшее решение - замена одного алгоритма на другой. И уж точно никто не опускается до ассемблера в наше время.
ministr_two,
ну во-первых, большинство современных программистов вообще нибудут лепить никаких вызовов, это задача компилятора, а во-вторых, извиняюсь, но всё в этой цитате - бред.Вот простой пример (первый, пришедший на ум): допустим мы разрабатываем простое приложение на ассемблере (пусть это необходимо) и совсем нет необходимости использовать 32х битную адрессацию, те. достаточно 16и битной. Я готов спорить, что большинство "современных программистов" будут лепить бызов 32х битных регистров, вот в этом самом месте никакие встроенные оптимизаторы не помогут, а достаточно всего лишь поменять вызовы и вставить директиву компилятора ( !важно - у всех компиляторов они "разные" (уже с обобщением) и это (хотя и не только) я подразумеваю под низкоуровневой оптимизацией) использовать 16 битный режим, тогда вскорость работы программы увеличится (в зависимости от количества вызовов) где-то на 20%.
При отказе от этой технологии можно только писать трояны да вирусы, размер в самый раз, и функциональность VCL не особо требуется :cheesy: Про заметное возрастание скорости опять же - чушь. Пример действительно лажевый.Еще пример - Delphi, зачем писать программы среднего класса ( не огромные проекты - RTTI рулит) с использованием VCL? при отказе от этой технологии размер выходного бинарика упадет точно на 70-80% и скорость заметно вырастет. Это пример оптимизации технологии хоть и лажевый.
тут я конечно "упал пацтул". Надеюсь имеется чёткое представление что такое стек в понятии STL, и что такое стек в понятии ассемблера?А теперь насчет asm-вставок, тоже на примере: ты пишешь игру, используешь стек, но твоя реализация стека например на STL, а что быстрее работает комманды проца pop and push или реализация на STL?
Вот эту фразу непонял, по-подробней пожалуйста. И ещё, нужно чётко осознавать что такое преждевременная оптимизация и преждевременная пессимизация. В грамотном коде отсутствует как первое так и второе.Кстати, грамотного кода без оптимизации мало.
Статейка по теме
http://rsdn.ru/article/philosophy/Optimization.xml
http://rsdn.ru/article/philosophy/Optimization.xml
Люблю повеселиться, особенно пожрать,
Люблю и поработать, особенно поспать )
Люблю и поработать, особенно поспать )
- DeLL
- СуперМодератор
- Сообщения: 2730
- Зарегистрирован: Ср июл 06, 2005 15:11
- Откуда: Мухосранск
- Контактная информация:
Eraser,
Проектирование, прокладка локальной/корпоративной сети, настройка серверов MS, любого сетевого оборудования
Шахтинское online-телевидение
Европа плюс Шахты on-air
Шахтинское online-телевидение
Европа плюс Шахты on-air
ministr_two,
и получим еще более медленную программу..
Складывается впечатление, что недостаточно практики в совокупности с большой учебной базой...
но только без обид...
По поводу оптимизации - согласен с мнением JokerR и Eraser,
Оптимизировать критические участки кода необходимо!!! Иначе, действительно - получим программу, которая неоправданно жрет немеряно ресурсов... Очень плохо, что некоторые программисты, привыкшие к постоянному повышению мощности ПК, перестали уделять такой оптимизации внимание. Ведь мощь наращивается совсем не для того, чтобы программист вообще перестал думать над кодом...
гм... точно - бред.необходимости использовать 32х битную адрессацию, те. достаточно 16и битной
и получим еще более медленную программу..
Складывается впечатление, что недостаточно практики в совокупности с большой учебной базой...
но только без обид...
По поводу оптимизации - согласен с мнением JokerR и Eraser,
Оптимизировать критические участки кода необходимо!!! Иначе, действительно - получим программу, которая неоправданно жрет немеряно ресурсов... Очень плохо, что некоторые программисты, привыкшие к постоянному повышению мощности ПК, перестали уделять такой оптимизации внимание. Ведь мощь наращивается совсем не для того, чтобы программист вообще перестал думать над кодом...