НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

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

Андрей Колесов
03.12.2012 11:30:26

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

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



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

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

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

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

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

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

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

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

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

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

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

Комментариев: 13

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

03.12.2012 17:52:27

Ну, важность быстрого компилятора и быстрого кода никто не отменялsmile:)

Не знаю, смогу ли поучаствовать, было бы интересно узнать:
- какое соотношение в процентах в России между Intel Parallel Studio XE и Microsoft Visual Studio?
- если соотношение неизвестно, то сколько штук этой Intel IDE продается у нас в год?
- кто вообще пользователи этой среды, какова целевая аудитория?
- почему нету бесплатной версии, по аналогии с Microsoft Visual Studio Express?
- компилятор из Intel Parallel Studio XE 2013 выдает код, на 50% быстрее микрософтовского -- ну и что?smile:)


03.12.2012 18:22:13

У нас есть неделя для предварительного обсуждения и вопросов.

У меня есть тоже много вопросов.
Например, хотелось бы узнать:
- каково соотношение использования средств Интел в США и в России?
- локализованы ли средства для России?
- как поддерживается групповая работа и ALM?
- есть ли интеграция с Visual Studio и Team Foundation Server? (и с аналогичными IBM Rational)
- какое реальный результат можно ожидать от использования средств профилирования?

Отдельная куча вопросов по теме распараллеливания...

04.12.2012 11:00:21

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

Мы же на рынке! Как надоsmile:) -- темы должны бытьь в духе "почему отрасль xxx (нефть, газ, ...) не может обойтись без инструментария Intel".

04.12.2012 11:18:08

Цитата
д можно сделать эффективным только с помощью инструментария разработчика


"Позвольте не согласиться с вами, профессор" (помните замечательный диалог двух музыкальных процессоров в "Иван Антонович сердится"?)

1. Я настаиваю на тезисе о том, что код должен быть ОПТИМАЛЬНЫМИ, а не эффективным. Оптимальный - это значит, что уровень эффективности должен соответствовать решаемой задаче.

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

04.12.2012 12:07:03

Так об этом и речь -- зачем Интел рассказывает про 3-4-ю позиции, когда лучше рассказывать про первые позиции. Наверняка у них есть свое отделение, ответственное за методологии жизненного цикла разработки ПО, аналогичное IBM Rational, вот пусть в его контексте и рассказывают про инструментарий.

04.12.2012 06:16:30

Недавно компилировал 0A.D., игрушка такая есть свободная - играю иногда, компилю всякие игрушки
компилилось около 25 минут.

1. Жутко как то, надо думать над скоростью компиляторов
2. Графика конечно потрясная, но чуть поиграл - тормозит нереально, такое впечатление что сложность алгоритмов -> O(n^2)
3. Размер скомпилированного модуля - 90 Mb, не слишком ???

Вопрос встаёт уже принципиальный, увеличением скорости компиляции в 2-3 раза ничего не решить, надо уменьшать количество фарша на входе.

04.12.2012 10:53:31

А чем компилировали-то? И как именно?

У вас разделяется процесс компиляции и компоновки (link)? Проще говоря: вы перекомпилируете только модифицированные модули или все подряд?

И что-то я вас не пойму: вас скорость компиляции не устраивает или качество кода?

04.12.2012 11:11:19

GNU C , под мандривой, из командной строки
по идее и скорость, и качество не устраивает

например, в UrbanTerror такая я же ситуация

по моему это путь в никуда, слишком большая сложность с алгоритмами, как то проще оно может делаться.

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

Хотя это моё субъективное мнение

04.12.2012 11:19:57

А как смена языка помогает решать проблемы со сложность алгоритма? Не понятно...

04.12.2012 11:25:03

Очень просто, заморочек меньше

04.12.2012 12:07:57

Помогает -- например, функциональные языки давно предлагают парадигму "что делать", а императивные лишь "как делать".

04.12.2012 12:11:46

"Она осталась жить на Киевской, а он переехал на Киевскую" smile:-)
И те и другие - "как делать"?

10.12.2012 10:55:00

Более подробно вопросы об использовании программных инструментов 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 для эффективного выполнения соответствующих этапов.

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

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии