НовостиОбзорыСобытияIT@WorkРеклама
Идеи и практики автоматизации:

Блог

Нужно ли бороться за эффективность программного кода? В каких случаях и зачем? Как?

Вот с таких вопросом мне бы лично хотелось бы начать разговор на очередном вебинаре, который PCWeek проводит с экспертами компании Intel через неделю с небольшим  - 12.12.12 (следующая среда) в 11:00 (я предлагал воспользоваться случаем и начать мероприятие 12.12.12 в 12:12, но идея  не нашел понимания у организаторов).

Сам вебинар называется "“Как с помощью инструментария разработчика сделать программный код эффективным”, подробнее о теме и зарегистрироваться – тут.



Модератором быть доверено мне, а экспертами на нем будут выступать две сотрудницы Нижегородского исследовательского центра Intel Екатерина Антакова (разработчик программных инструментов компании Intel), Галина Санжарлинская (специалист по продвижению ПО Intel).

Если кто не очень в курсе – многие инструменты разработчика Intel делаются именно в России, в Нижнем. Кстати, в том числе и по этому поводу у меня было ровно год назад интервью с гендиректором по исследованиям и разработкам Intel в России Камилем Исаевым.

Но все же вернемся к теме вебинара. [spoiler]Я, со своей стороны, вопрос "надо ли бороться за эффективность?" предложил вынести в заголовок разговора в целом. Но идею мою не поддержали, посчитали, что это вопрос риторический, ответ очевиден – "да, конечно!"

Не знаю, возможно, я сильно отстал от жизни, и за последние 10 лет (с тех пор, как я написал свой последний "боевой" – для реального применения – программный код) что-то в мире программирования сильно изменилось, но для меня (все же активно программировал почти 30 лет) ответ не является очевидным. И является принципиально важным.

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

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

По-моему, этот тезис является довольно очевидным. Нужно ли, чтобы городской автомобиль мог разгоняться до скорости 300 км в час, если движение в городах ограниченном 60-80 км, а на магистралях – 110-130?
Нужно ли вкладывать 100 у.е. в улучшение кода, если выгода от улучшения не превысит 10 у.е.?

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

А вот как определить оптимальность и как можно достичь ее – вот это вопрос, из разряда вечных. В том плане, что мы никогда не сможет дать на него точного ответа, но при этом все время должны заниматься поиском ответа.

Что я все же и попробую в предстоящей веб-беседе с экспертами из Нижнего Новгорода.

А что вы думаете по этому поводу?
Какие темы вам было бы интересно обсудить, какие вопросы хотелось бы задать реальными разработчикам средств разработки Intel?

Сергей Бобровский
Помогает -- например, функциональные языки давно предлагают парадигму "что делать", а императивные лишь "как делать".
Колесов Андрей
"Она осталась жить на Киевской,  а он переехал на Киевскую" :-)
И те и другие - "как делать"?
Денис Макошенко
Более подробно вопросы об использовании программных инструментов Intel и о преимуществах, которое они дают, будут рассмотрены на вебинаре 12 декабря, пока же хотелось бы сделать несколько комментариев:

- локализованы ли средства для России?
Нет, Parallel Studio XE и Cluster Studio XE не локализованы для России. Интерфейсы и документация у них только на английском языке.

- как поддерживается групповая работа и ALM?  
При групповой разработке больших приложений имеет смысл встраивать запуск инструментов Amplifier XE, Inspector XE в режиме командной строки в систему регулярной проверки производительности и контроля качества. Инструменты позволяют сравнивать результаты разных запусков и таким образом отслеживать прогресс в улучшении производительности и в улучшении корректности кода.
Кроме того, инструмент Inspector XE  позволяет различным разработчикам работать со своей копией результатов анализа, а затем объединять работу в один итоговой результат. Таким образом присвоенные состояния найденных ошибок («Исправлена», «Отложена», «Подтверждённая проблема», «Регрессия») будут наследоваться. Также, в команде разработчиков удобно использовать общие правила подавления сторонних ошибок для Inspector XE.

- есть ли интеграция с Visual Studio и Team Foundation Server? (и с аналогичными IBM Rational) -???
У обоих пакетов  Parallel Studio XE и Cluster Studio XE есть интеграция в Visual Studio. Работа с Team Foundation Server осуществляется в контексте работы с Visual Studio. Специализированной поддержки Team Foundation Server не требуется. Интеграция с продуктами IBM Rational не поддерживается.

- какой реальный результат можно ожидать от использования средств профилирования?
Средства профилирования дают картину работы приложения с точки зрения загруженности процессора, количества и последовательности исполнения потоков, количества ожиданий и блокировок в приложении. Они также показывают распределение времени работы приложения в его отдельных модулях, функциях. Есть возможность осуществлять event-based sampling и event-based profiling. Таким образом, пользователю доступна полная информация о работе приложения на конкретном CPU c привязкой этой информации к исходному коду приложения. На основании этих данных можно сделать выводы об и эффективности использования доступных ресурсов CPU и памяти и возможных способах улучшения производительности приложения В частности на основании соответствующих событий можно сделать выводы о работе подсистемы кэшей, эффективности работы с памятью, качества загрузки CPU front-end, ошибок предсказания переходов, использования неэффективных инструкций, качества распараллеливания программы, влияния блокировок и т.п .   А результаты оптимизации зависят во многом от приложения, от того, насколько оно допускает, например, введение параллелизма, векторизации. Некоторые приёмы оптимизации на основе результатов профилировки опубликованы в статьях на Habrahabr: http://habrahabr.ru/company/intel/blog/142382/, http://habrahabr.ru/company/intel/blog/140965/.
Более подробно о возможностях vTune Amplifier XE можно прочитать здесь
http://software.intel.com/en-us/intel-vtune-amplifier-xe

-жизненный цикл разработки ПО
Parallel Studio XE и Cluster Studio XE предоставляют набор инструментов, которые могут повысить эффективность разработчика на различных этапах жизненного цикла разработки ПО.
Инструмент Advisor XE помогает уже на стадии анализа, прототипирования и создания архитектуры приложения. Компилятор, оптимизирующие библиотеки MKL, IPP, и библиотеки параллельного программирования используются на этапе реализации программы, Inspector XE помогает в тестировании, проверке корректности и контроле качества  приложения, a Amplifier XE помогает найти узкие места в производительности и оптимизировать разработанное приложение. Также, для оптимизации производительности большую роль играют такие средства, как, библиотеки и расширения языков: Cilk Plus, TBB, OpenMP, Fotran CoArray. Parallel Studio XE и Cluster studio XE не являются инструментами ALM или PLM. Разработчик может выбрать любую систему управления жизненным циклом разработки приложения и использовать инструменты Intel для эффективного выполнения соответствующих этапов.

Денис Макошенко, руководитель Московской компиляторной лаборатории компании Интел.