Около двух месяцев назад состоялся первый экспериментальный русскоязычный онлайн-семинар от Intel "Intel Parallel Studio workflow". На этом семинаре была сделана попытка показать, что существуют такие волшебные инструменты, которые помогут реализовать распараллеливание и оптимизацию кода на языке Си++, даже если вы не имеете полного представления о принципах работы программы. Я знаю, что подобный подход часто критикуется. И очередное напоминание, что показанные на вебинаре действия являются некорректными, сподвигло меня на этот пост.
Аналогичные разногласия существовали когда-то между сторонниками и противниками использования инструментов отладки («дебаггеров»). Противники утверждали, что отладчики являются следствием неверной методологии, а пользователи отладчиков просто малограмотны. Основной их аргумент заключался в том, что использование инструментов отладки поощряет написание кода методом проб и ошибок, без попытки как следует продумать алгоритм и переписать его, разбить на маленькие функции, сделать более лаконичным и простым — таким, чтобы не осталось места для ошибок. Поскольку противников инструментов отладки сейчас мало, то многие, возможно, даже не слышали о подобных спорах. Ну а сейчас мы наблюдаем начало нового витка.
В настоящее время сформировались и обсуждаются два подхода к проблеме распараллеливания программ. Сторонники первого хотят получить какие-то средства, которые позволят им при минимальной переделке программы осуществить ее распараллеливание. Это практики, которые хотят приспособить свои решения к возможностям многоядерных систем, появляющихся на столах обыкновенных пользователей. Вторые любят поговорить о различных теориях распараллеливания, о языках параллельного программирования и том, что необходимо четко понимать, как будет работать параллельный код. Ведь, по их мнению, иначе невозможно достичь его корректности и эффективности.
Я согласен со второй группой, которая призывает к осознанным действиям, будь то отладка или эксперименты с использованием директив OpenMP. Такой подход провоцируют создание менее надежных программ, ведь работоспособным кодом признается не корректный код, а код, который корректно работает на ряде тестов. Это, безусловно, плохо. Но душой я полностью поддерживаю первую группу.
Я практик. И считаю, что уже давным-давно никто не знает, как работают реальные программы. И нет смысла говорить, понятна отлаживаемая или распараллеливаемая программа разработчику или нет. Она всегда непонятна, если мы говорим о промышленной разработке ПО. Противники «теории черного ящика» (первая группа) являются в основном представителями академических кругов, преподавателями или людьми, занимающихся решением узких задач, где важна крайняя эффективность параллельности. Например, численное программирование. Обычно они имеют дело с прототипами программ, которые что-то вычисляют, в которых они хорошо разбираются и знают, какие алгоритмы распараллеливания следует применять в каждом конкретном случае. Программы невелики, их можно прочитать или даже при необходимости переписать заново — на другом языке. Ошибка в том, что они пытаются масштабировать свой опыт на большие программные проекты.
Аналогия со второй группой (теоретики, или противники черного ящика). Человек с фонариком и лупой, который с интересом изучает красивый сундук, покрытый росписью и предлагает способы как сделать его еще более красивым и удобным в использовании.
Реальный программист, занимающийся развитием большого проекта, разрабатываемого годами или даже десятилетиями, находится в совершенно иных условиях. Скорее всего, он пришел в проект, когда уже написаны мегабайты кода и он не знает всю историю тех или иных архитектурных решений. Возможно, ему даже не у кого спросить. Он не имел времени прочитать исходные коды, и никогда не будет иметь столько времени. Он работает на определенном участке работ и может не представлять, как работают многие алгоритмы, написанные задолго до его прихода в группу разработки, но которые он вынужден использовать.
Аналогия с первой группой (практики, или сторонники черного ящика). Человек с фонариком и лупой в огромном лабиринте. Он может внимательно изучать фрески на стенах, но луч фонаря не может высветить противоположные стены и позволяет видеть коридоры лабиринта только фрагментами, не создавая целостной картины.
Я не считаю подход к параллельному программированию, как к эксперименту с черным ящиком, хорошей методологией. Но она лучше, чем не делать ничего или предлагать, полностью разобраться в структуре имеющегося программного комплекса и алгоритмов. Это, к сожалению, просто не получается. Сложность многих программных решений переросла возможности сознания отдельных людей и даже коллективов, которые с ними работают. Использование специализированных инструментов, которые позволяют как-то решить задачу распараллеливания и отладки является единственным доступным вариантом. Опыт разработки крайне эффективной, но маленькой параллельной программы здесь не применим.
Профайлер не предложит высокоуровневый способ изменения алгоритма. Но он покажет, как можно хотя бы частично ускорить программу, распараллелив наиболее критичные участки кода. Параллельный отладчик или анализатор кода не докажут корректность параллельной программы. Но они позволят подстраховать программиста, забывшего посветить фонариком в одном из направлений и тем самым упустившего от взгляда важный элемент.
Я поддерживаю методику использования инструментов, позволяющих и помогающих распараллелить не только хорошо понимаемый код, но и черные ящики, как практически единственный способ работы с большими программными системами.
Аналогичные разногласия существовали когда-то между сторонниками и противниками использования инструментов отладки («дебаггеров»). Противники утверждали, что отладчики являются следствием неверной методологии, а пользователи отладчиков просто малограмотны. Основной их аргумент заключался в том, что использование инструментов отладки поощряет написание кода методом проб и ошибок, без попытки как следует продумать алгоритм и переписать его, разбить на маленькие функции, сделать более лаконичным и простым — таким, чтобы не осталось места для ошибок. Поскольку противников инструментов отладки сейчас мало, то многие, возможно, даже не слышали о подобных спорах. Ну а сейчас мы наблюдаем начало нового витка.
В настоящее время сформировались и обсуждаются два подхода к проблеме распараллеливания программ. Сторонники первого хотят получить какие-то средства, которые позволят им при минимальной переделке программы осуществить ее распараллеливание. Это практики, которые хотят приспособить свои решения к возможностям многоядерных систем, появляющихся на столах обыкновенных пользователей. Вторые любят поговорить о различных теориях распараллеливания, о языках параллельного программирования и том, что необходимо четко понимать, как будет работать параллельный код. Ведь, по их мнению, иначе невозможно достичь его корректности и эффективности.
Я согласен со второй группой, которая призывает к осознанным действиям, будь то отладка или эксперименты с использованием директив OpenMP. Такой подход провоцируют создание менее надежных программ, ведь работоспособным кодом признается не корректный код, а код, который корректно работает на ряде тестов. Это, безусловно, плохо. Но душой я полностью поддерживаю первую группу.
Я практик. И считаю, что уже давным-давно никто не знает, как работают реальные программы. И нет смысла говорить, понятна отлаживаемая или распараллеливаемая программа разработчику или нет. Она всегда непонятна, если мы говорим о промышленной разработке ПО. Противники «теории черного ящика» (первая группа) являются в основном представителями академических кругов, преподавателями или людьми, занимающихся решением узких задач, где важна крайняя эффективность параллельности. Например, численное программирование. Обычно они имеют дело с прототипами программ, которые что-то вычисляют, в которых они хорошо разбираются и знают, какие алгоритмы распараллеливания следует применять в каждом конкретном случае. Программы невелики, их можно прочитать или даже при необходимости переписать заново — на другом языке. Ошибка в том, что они пытаются масштабировать свой опыт на большие программные проекты.
Аналогия со второй группой (теоретики, или противники черного ящика). Человек с фонариком и лупой, который с интересом изучает красивый сундук, покрытый росписью и предлагает способы как сделать его еще более красивым и удобным в использовании.
Реальный программист, занимающийся развитием большого проекта, разрабатываемого годами или даже десятилетиями, находится в совершенно иных условиях. Скорее всего, он пришел в проект, когда уже написаны мегабайты кода и он не знает всю историю тех или иных архитектурных решений. Возможно, ему даже не у кого спросить. Он не имел времени прочитать исходные коды, и никогда не будет иметь столько времени. Он работает на определенном участке работ и может не представлять, как работают многие алгоритмы, написанные задолго до его прихода в группу разработки, но которые он вынужден использовать.
Аналогия с первой группой (практики, или сторонники черного ящика). Человек с фонариком и лупой в огромном лабиринте. Он может внимательно изучать фрески на стенах, но луч фонаря не может высветить противоположные стены и позволяет видеть коридоры лабиринта только фрагментами, не создавая целостной картины.
Я не считаю подход к параллельному программированию, как к эксперименту с черным ящиком, хорошей методологией. Но она лучше, чем не делать ничего или предлагать, полностью разобраться в структуре имеющегося программного комплекса и алгоритмов. Это, к сожалению, просто не получается. Сложность многих программных решений переросла возможности сознания отдельных людей и даже коллективов, которые с ними работают. Использование специализированных инструментов, которые позволяют как-то решить задачу распараллеливания и отладки является единственным доступным вариантом. Опыт разработки крайне эффективной, но маленькой параллельной программы здесь не применим.
Профайлер не предложит высокоуровневый способ изменения алгоритма. Но он покажет, как можно хотя бы частично ускорить программу, распараллелив наиболее критичные участки кода. Параллельный отладчик или анализатор кода не докажут корректность параллельной программы. Но они позволят подстраховать программиста, забывшего посветить фонариком в одном из направлений и тем самым упустившего от взгляда важный элемент.
Я поддерживаю методику использования инструментов, позволяющих и помогающих распараллелить не только хорошо понимаемый код, но и черные ящики, как практически единственный способ работы с большими программными системами.
