Аннотация:
В этом эссе доктор Ньюкамер делится своим опытом и соображениями по поводу преждевременной, несвоевременной или неактуальной оптимизации, призывая программистов избежать подобных ошибок.
...Вот, взял на себа труд перевести заключение к этой статье. А то без него эта
вполне разумная и наталкивающая на очень полезные размышления статься превращется
в махровый флэймбайт...
Заключение:
Оптимизация нужна только там где она важна. И когда она нужна, она очень важна, но пока вы не узнаете где она нужна, не тратьте слишком много времени на нее. Даже если вы знаете о ее важности, вы не знаете где она пригодится. Без данных о производительности программы вы не узнаете где ее нужно оптимизировать и скорее всего соптимизируете не то что надо.
В результате вы получите нечитаемый, трудно поддающийся отладке код который не решит вашу проблему. И, следовательно, он несет двойной набор недостатков: (а) увеличение трудоемкости разработки и поддержки программы и (б) отсутствие положительного эффекта на производительность.
Тяжело решить эту проблему. Теперь, вы понимаете что я имел в виду?
В принципе, все верно. И статья эта не более и не менее чем разьяснение "древнего" принципа "Preamture optimization is a root of all evil". Она несомненно нужна и полезна.
Проблема только в том, что категорические императивы подобные этому имеют весьма ограниченное поле применения. Попробую очертить рамки этого поля.
— Предполагается что программист все-таки имеет навыки оптимизации и не напишет заведомо неоптимальный код. Например, такой: http://rsdn.ru/forum/?mid=1074689
— Предполагается что оптимальный код есть "трудно читаемый" код. ИМХО, это в корне неверно.
Зачастую, оптимальность достигается путем применения алгоримов подходящих для решения проблемы и грамотного использования свойств языка. То есть, программист должен свободно ориентироваться в доступном ему инструментарии. В свете этого, пример с аллокацией 5-10 байт в часто используемой функции есть не столько вопрос оптимизации, сколько вопрос профессилнальной компетентности программиста.
— Совершенно не освещен вопрос оптимальности повторно используемого (библиотечного) кода. А ведь этот код может быть использован в ЛЮБОМ месте программы. То есть, он заведомо оптимален. То есть предполагается что код который "должен быть оптимальным" уже кем-то написан до нас. ИМХО, это далеко не так во всех смыслах. Во-первых, не существует алгоритмов оптимальных для любых случаев. И, во вторых, зачастую авторы библиотек также руководствуются принципами изложенными в этой статье.
Posted via RSDN NNTP Server 1.9
__________
16.There is no cause so right that one cannot find a fool following it.
Надо было вниматльно читать статью, а не переводить ее заключение. Там про все аспекты хорошо сказано.
К тому же сказано не кем-то с бугра, а:
Немного общей информации: моя докторская работа была одной из первых работ по автоматической генерации оптимизирующих компиляторов из формального машинного описания («Машинно-независимая генерация оптимального кода», университет Карнеги-Меллона (в дальнейшем CMU – прим. перев.), кафедра информатики, 1975). После защиты докторской я провел три года в CMU в качестве ведущего исследователя многопроцессорной компьютерной системы Cmmp, использовавшей нашу местную операционную систему Hydra, безопасную и высокопроизводительную. Затем я вернулся к исследованию компиляторов на проекте PQCC (компилятор компиляторов промышленного уровня), который, в конечном счете, привел к основанию лабораторий Tartan (сейчас поглощены Texas Instruments) – компании по разработке компиляторов, в которой я работал в инструментальной группе. Я провел полтора десятка лет за написанием и использованием инструментов измерения производительности.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В одном не могу согласиться — очень уж мне не понравился последний пример. Он немного не о том. Тут речь идет не столько о неоправданной оптимизации — она-то только приводит к лишним трудозатратам и подчас ухудшению легкости понимания кода, но не к снижению портабельности. Снижение портабельности — само по себе, пусть даже оно часто является необходимым условием оптимизации (не всегда и не всякой!).
Более того, код, вероятно, изначально нужно было писать именно под 16-битную систему, без прямого указания на ориентацию на повышение разрядности. Невозможно предугадать решительно все направления, в которых могут развиваться системы, на которые предполагается в будущем ставить данный продукт... Если на то пошло, можно и за привязку к IP4 ругать программера, не предусмотревшего-таки, каналью, 10 лет назад возникновение IP6, и выделившего в своем коде ровно 4 байта на хранение айпишника.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
АЛП>Авторы: АЛП> Андрей Лягусский (перевод)
АЛП>Аннотация: АЛП>В этом эссе доктор Ньюкамер делится своим опытом и соображениями по поводу преждевременной, несвоевременной или неактуальной оптимизации, призывая программистов избежать подобных ошибок.
Не знаю как кому, но после прочтения статьи мне больше запомнились не доводы за и/или против оптимизации, а то что Dr. Joseph M. Newcomer чрезвычайно крут: он написал докторскую, книгу по высокопроизводительным распределителям памяти, и, как следствие, заработал право среди коллег опускать Unix.
Здравствуйте, Андрей Лягусский (перевод), Вы писали:
АЛП>Аннотация: АЛП>В этом эссе доктор Ньюкамер делится своим опытом и соображениями по поводу преждевременной, несвоевременной или неактуальной оптимизации, призывая программистов избежать подобных ошибок.
Рискну добавить пару слов о своих наблюдениях за профайлерами. Профайлеры были актуальны в времена примитивных прцессоров, типа 8086. Сайчас же все стало настолько сложно, что верить профайлерам нельзя. Не знаю насчет Интеловского VTune, но чтобы получить адекватную оценку, нужно фактически программно сэмурировать весь процессор. У меня, например, профайлер из NuMega на некоторых тестах врет в 3-4 раза по соотношению времен выполнения неких критических участков. То же самое — со встроенным профайлером в VC6. Таким образом, профайлером можно отследить только участки с точностью до порядка. То есть, если профайлер показывает, соотношение времен двух функций 90 к одному, то скорее всего первая функция действительно выполняется медленнее, причем ее вклад может составлять как 70%, так и 99%. Профайлер сбивает все конвейеры и кэш и вообще, путается под ногами и мешает процессору нормально работать. Реальную картину может показать только непосредственное измерение, выполненное в боевом режиме.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Рискну добавить пару слов о своих наблюдениях за профайлерами. Профайлеры были актуальны в времена примитивных прцессоров, типа 8086. Сайчас же все стало настолько сложно, что верить профайлерам нельзя. Не знаю насчет Интеловского VTune, но чтобы получить адекватную оценку, нужно фактически программно сэмурировать весь процессор. У меня, например, профайлер из NuMega на некоторых тестах врет в 3-4 раза по соотношению времен выполнения неких критических участков.
Незнаю как там NuMega, но буквально недавно баловался с профайлером из новй студии (2005 Тим...) и он показал довольно точные результаты. Прада для управляемого кода. Ну, и тормозил он очень сильно.
Но точно, что тезисо о современных процессорах все же не совсем верен.
MS> То же самое — со встроенным профайлером в VC6.
Слушай, выбрасил бы ты его на свалку истории. А то скоро молодое поколение уже не будет понимать о чем ты речь ведешь. Темболее что компилятор на сегодня полная фигня по всем показателям.
MS> Таким образом, профайлером можно отследить только участки с точностью до порядка. То есть, если профайлер показывает, соотношение времен двух функций 90 к одному, то скорее всего первая функция действительно выполняется медленнее, причем ее вклад может составлять как 70%, так и 99%. Профайлер сбивает все конвейеры и кэш и вообще, путается под ногами и мешает процессору нормально работать. Реальную картину может показать только непосредственное измерение, выполненное в боевом режиме.
Любое измерение вносит погрешнось. Даже сэмплинг. Но радует только то, что погрешность эта однородна. Так что уловить тенденцию и найти действительно тормозные куски все же можно. А там уже нужно прилагать свой опыт и чутье.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
MS>> То же самое — со встроенным профайлером в VC6.
VD>Слушай, выбрасил бы ты его на свалку истории. А то скоро молодое поколение уже не будет понимать о чем ты речь ведешь. Темболее что компилятор на сегодня полная фигня по всем показателям.
VC6 мне нравится ураганной скоростью компиляции при приемлемом качестве оптимизации. Я и во времена 386-486 продолжал использовать Turbo-C 2.0 именно по этой причине. Вот такой я ретроград. Это первое. Второе — это то, что отказ от поддержки VC6 для меня означает потерю чуть ли не половины моих потенциальных заказчиков. И этот аргумент перевешивает любые распальцовки с 8-ми бетами.
VD>Любое измерение вносит погрешнось. Даже сэмплинг. Но радует только то, что погрешность эта однородна. Так что уловить тенденцию и найти действительно тормозные куски все же можно. А там уже нужно прилагать свой опыт и чутье.
Моя практика говорит об обратном, а именно о том, что профайлер вносит именно существенную случайную погрешность. Точнее сказать, теоретически он конечно же вносит систематическую погрешность, но количество состояний и условий настолько велико, что не представляется возможным эту погрешность хоть как-то систематизировать. На практике это эквивалентно внесению случайной погрешности. Но это на "никем не управляемом" (unleashed) коде.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
McSeem2 wrote:
> АЛП>*Аннотация:* > АЛП>В этом эссе доктор Ньюкамер делится своим опытом и соображениями > по поводу преждевременной, несвоевременной или неактуальной > оптимизации, призывая программистов избежать подобных ошибок. > Рискну добавить пару слов о своих наблюдениях за профайлерами. > Профайлеры были актуальны в времена примитивных прцессоров, типа 8086. > Сайчас же все стало настолько сложно, что верить профайлерам нельзя.
Можно, но не всем.
> Не знаю насчет Интеловского VTune, но чтобы получить адекватную > оценку, нужно фактически программно сэмурировать весь процессор.
Именно так и сделано в VTune — в нем есть режимы, когда он показывает в
скомпилированном ассемблерном коде места, где происходят срывы конвейера
или неоптимальное распараллеливаниеи и т.п. Причем можно выбрать для
анализа любой современный тип процессора.
> У меня, например, профайлер из NuMega на некоторых тестах врет в 3-4 > раза по соотношению времен выполнения неких критических участков.
Значит менять его надо. Мои собственные мини-исследования показали, что
лучше всего себя ведет Intel VTune + Intel C++.
> То есть, если профайлер показывает, соотношение времен двух функций 90 > к одному, то *скорее всего* первая функция действительно выполняется > медленнее, причем ее вклад может составлять как 70%, так и 99%. > Профайлер сбивает все конвейеры и кэш и вообще, путается под ногами и > мешает процессору нормально работать.
Отличная статья. Самое "обидное", что через все это пришлось пройти самостоятельно. Вот некоторые из моих примеров:
В большом рекурсивном коде, связанном с рассчетом анимации моделей (поиск значения по 9 сплайнам, рассчет матриц трансформации 4*4 и т.д.) код установки бита "матрица подсчитана" (object_state |= 0x0001) занимал 7% всего времени из-за перезагрузки кэша.
Вызов одной из функций был ускорен в несколько раз, когда я потребовал от программистов переписать код локально создаваемого класса вида
Заметь он пишет что , Хоть мало мальски квалифицированный программист не будет сразу слишком неоптимальный код.
То есть он даже не рассматривает вариант когда код пишется профанами.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: можно и за привязку к IP4 ругать программера
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>В одном не могу согласиться — очень уж мне не понравился последний пример. Он немного не о том. Тут речь идет не столько о неоправданной оптимизации — она-то только приводит к лишним трудозатратам и подчас ухудшению легкости понимания кода, но не к снижению портабельности. Снижение портабельности — само по себе, пусть даже оно часто является необходимым условием оптимизации (не всегда и не всякой!). SM>Более того, код, вероятно, изначально нужно было писать именно под 16-битную систему, без прямого указания на ориентацию на повышение разрядности. Невозможно предугадать решительно все направления, в которых могут развиваться системы, на которые предполагается в будущем ставить данный продукт... Если на то пошло, можно и за привязку к IP4 ругать программера, не предусмотревшего-таки, каналью, 10 лет назад возникновение IP6, и выделившего в своем коде ровно 4 байта на хранение айпишника.
SM>Slicer
Еще как можно ругать если он выделил 4 байта под айпишник в серьезной системе и НЕ НАПИСАЛ КОД обрабатывающий ошибку при использовании IPV6, хотя для системы 10 летней давности такой айпишник был бы просто некоректным ! и сообщение об ошибке должно было на этапе парсинга появится.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: можно и за привязку к IP4 ругать программера
Здравствуйте, minorlogic, Вы писали: M>Еще как можно ругать если он выделил 4 байта под айпишник в серьезной системе и НЕ НАПИСАЛ КОД обрабатывающий ошибку при использовании IPV6, хотя для системы 10 летней давности такой айпишник был бы просто некоректным ! и сообщение об ошибке должно было на этапе парсинга появится.
Ну-ну. Если в VC 7.0 включить режим Detect 64-bit portability, то половину программистов на планете надо будет просто перестрелять за то, что они не думали о будущих платформах
Жизнь — игра. Замысел хреновый, но графика — обалденная
Дело в том что при существовании Vtune остальные курят в сторонке , а профайлер из vc6 это вообще не профайлер а вентилятор для неокрепших умов. Про него советую забыть НАВСЕГДА, забыть что он вааще есть ..
Кстати сам пользуюсь самодельным профайлером , который включаю только на интересующих участках кода. Работает как часыю причем не помню случая чтобы тормозил в рантайме (Vtune сильно тормозит).
На работе пользуюсь Vtune.
Эх , история недавно была ! Работаю над декодером одного из медиа форматов. От заказчика , после ИЗУЧЕНИЯ КОДА приходит требование вынести кучу функцций в инлайн.
Я как посмотрель какие доли процента эти функции занимают в профайлере ... было бы смешно если бы не мне всю эту дрянь делать было.
Вообще историй про "оптимизации" мог бы кучу рассказать ... И про переписывание РЕСУРСОЕМКИХ функций (жуткая функция для психоакустики с FFT на double) на ассемблере и много чего забавного ...
Ксатии про оптимизацию http://www.minorlogic.com/projects/smartblend/index.htm
Меня все время спрашивают почему она так быстро работает ? Видимо я переписал все на SSE2 и т.д. А мне вроде как и неудобно рассказвать , что для доступа к пикселям изображения у меня используется ВИРТУАЛЬНАЯ функция.
Дело в том что у аналогичной программы делающей похожие вещи, вся обработка изображений сделана на VIGRA , которая максимально использует темплейты и вроде как должна инлайнится и показывать жуть какие высоты быстродействия ...
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: можно и за привязку к IP4 ругать программера
Здравствуйте, _Dimka_, Вы писали:
_D_>Ну-ну. Если в VC 7.0 включить режим Detect 64-bit portability, то половину программистов на планете надо будет просто перестрелять за то, что они не думали о будущих платформах
Зачем так жестоко ? просто есть разные задачи и разные требования к коду. Кстати автор пишет о коде который не может себе позволить подобных вольностей . Например тот же распределитель памяти, если не будет обрабатывать ошибки ... или ченить в линуксь ядре ?
Я видело код , который запросто компилился и под разными платформами и компиляторами и даже разрядностями системы. В крайнем случае код сообщал об ошибке на этапе компиляции . И есть области применения где ЭТО считается нормой для кода .
M>Ксатии про оптимизацию M>http://www.minorlogic.com/projects/smartblend/index.htm M>Меня все время спрашивают почему она так быстро работает ? Видимо я переписал все на SSE2 и т.д. А мне вроде как и неудобно рассказвать , что для доступа к пикселям изображения у меня используется ВИРТУАЛЬНАЯ функция.
M>Дело в том что у аналогичной программы делающей похожие вещи, вся обработка изображений сделана на VIGRA , которая максимально использует темплейты и вроде как должна инлайнится и показывать жуть какие высоты быстродействия ...
Еще дядка Рихтер в своё время писал, что скомпилировав код с оптимизацией по размеру можно получить более быстрый код, по сравнению с оптимизацией по скорости.
MS>Еще дядка Рихтер в своё время писал, что скомпилировав код с оптимизацией по размеру можно получить более быстрый код, по сравнению с оптимизацией по скорости.
MS>По всей видимости у вас именно такой случай...
Типа комплимент в мой адрес ? да ? вроде как это у меня случайно получилось ? Нечаянно ? Ну пасиб , уважил ...
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: можно и за привязку к IP4 ругать программера
Здравствуйте, minorlogic, Вы писали:
M>Еще как можно ругать если он выделил 4 байта под айпишник в серьезной системе и НЕ НАПИСАЛ КОД обрабатывающий ошибку при использовании IPV6, хотя для системы 10 летней давности такой айпишник был бы просто некоректным ! и сообщение об ошибке должно было на этапе парсинга появится.
А ошибки не будет. Просто из того, что вернула система, он прочитает только 4 байта, и потом будет по ним пытаться достучаться. Никаких исключений, никаких утечек памяти, — конкретно код, получающий айпишник, отрабатывает гладко — просто возвращает после перехода на IPv6 неверный результат. Ошибка возникает позже. Как и в приведенном автором статьи примере.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
