Параллельное программирование в черном ящике
Около двух месяцев назад состоялся первый экспериментальный русскоязычный онлайн-семинар от Intel "Intel Parallel Studio workflow". На этом семинаре была сделана попытка показать, что существуют такие волшебные инструменты, которые помогут реализовать распараллеливание и оптимизацию кода на языке Си++, даже если вы не имеете полного представления о принципах работы программы. Я знаю, что подобный подход часто критикуется. И очередное напоминание, что показанные на вебинаре действия являются некорректными, сподвигло меня на этот пост.
Аналогичные разногласия существовали когда-то между сторонниками и противниками использования инструментов отладки («дебаггеров»). Противники утверждали, что отладчики являются следствием неверной методологии, а пользователи отладчиков просто малограмотны. Основной их аргумент заключался в том, что использование инструментов отладки поощряет написание кода методом проб и ошибок, без попытки как следует продумать алгоритм и переписать его, разбить на маленькие функции, сделать более лаконичным и простым — таким, чтобы не осталось места для ошибок. Поскольку противников инструментов отладки сейчас мало, то многие, возможно, даже не слышали о подобных спорах. Ну а сейчас мы наблюдаем начало нового витка.
В настоящее время сформировались и обсуждаются два подхода к проблеме распараллеливания программ. Сторонники первого хотят получить какие-то средства, которые позволят им при минимальной переделке программы осуществить ее распараллеливание. Это практики, которые хотят приспособить свои решения к возможностям многоядерных систем, появляющихся на столах обыкновенных пользователей. Вторые любят поговорить о различных теориях распараллеливания, о языках параллельного программирования и том, что необходимо четко понимать, как будет работать параллельный код. Ведь, по их мнению, иначе невозможно достичь его корректности и эффективности.
Я согласен со второй группой, которая призывает к осознанным действиям, будь то отладка или эксперименты с использованием директив OpenMP. Такой подход провоцируют создание менее надежных программ, ведь работоспособным кодом признается не корректный код, а код, который корректно работает на ряде тестов. Это, безусловно, плохо. Но душой я полностью поддерживаю первую группу.
Я практик. И считаю, что уже давным-давно никто не знает, как работают реальные программы. И нет смысла говорить, понятна отлаживаемая или распараллеливаемая программа разработчику или нет. Она всегда непонятна, если мы говорим о промышленной разработке ПО. Противники «теории черного ящика» (первая группа) являются в основном представителями академических кругов, преподавателями или людьми, занимающихся решением узких задач, где важна крайняя эффективность параллельности. Например, численное программирование. Обычно они имеют дело с прототипами программ, которые что-то вычисляют, в которых они хорошо разбираются и знают, какие алгоритмы распараллеливания следует применять в каждом конкретном случае. Программы невелики, их можно прочитать или даже при необходимости переписать заново — на другом языке. Ошибка в том, что они пытаются масштабировать свой опыт на большие программные проекты.
Аналогия со второй группой (теоретики, или противники черного ящика). Человек с фонариком и лупой, который с интересом изучает красивый сундук, покрытый росписью и предлагает способы как сделать его еще более красивым и удобным в использовании.
Реальный программист, занимающийся развитием большого проекта, разрабатываемого годами или даже десятилетиями, находится в совершенно иных условиях. Скорее всего, он пришел в проект, когда уже написаны мегабайты кода и он не знает всю историю тех или иных архитектурных решений. Возможно, ему даже не у кого спросить. Он не имел времени прочитать исходные коды, и никогда не будет иметь столько времени. Он работает на определенном участке работ и может не представлять, как работают многие алгоритмы, написанные задолго до его прихода в группу разработки, но которые он вынужден использовать.
Аналогия с первой группой (практики, или сторонники черного ящика). Человек с фонариком и лупой в огромном лабиринте. Он может внимательно изучать фрески на стенах, но луч фонаря не может высветить противоположные стены и позволяет видеть коридоры лабиринта только фрагментами, не создавая целостной картины.
Я не считаю подход к параллельному программированию, как к эксперименту с черным ящиком, хорошей методологией. Но она лучше, чем не делать ничего или предлагать, полностью разобраться в структуре имеющегося программного комплекса и алгоритмов. Это, к сожалению, просто не получается. Сложность многих программных решений переросла возможности сознания отдельных людей и даже коллективов, которые с ними работают. Использование специализированных инструментов, которые позволяют как-то решить задачу распараллеливания и отладки является единственным доступным вариантом. Опыт разработки крайне эффективной, но маленькой параллельной программы здесь не применим.
Профайлер не предложит высокоуровневый способ изменения алгоритма. Но он покажет, как можно хотя бы частично ускорить программу, распараллелив наиболее критичные участки кода. Параллельный отладчик или анализатор кода не докажут корректность параллельной программы. Но они позволят подстраховать программиста, забывшего посветить фонариком в одном из направлений и тем самым упустившего от взгляда важный элемент.
Я поддерживаю методику использования инструментов, позволяющих и помогающих распараллелить не только хорошо понимаемый код, но и черные ящики, как практически единственный способ работы с большими программными системами.
Аналогичные разногласия существовали когда-то между сторонниками и противниками использования инструментов отладки («дебаггеров»). Противники утверждали, что отладчики являются следствием неверной методологии, а пользователи отладчиков просто малограмотны. Основной их аргумент заключался в том, что использование инструментов отладки поощряет написание кода методом проб и ошибок, без попытки как следует продумать алгоритм и переписать его, разбить на маленькие функции, сделать более лаконичным и простым — таким, чтобы не осталось места для ошибок. Поскольку противников инструментов отладки сейчас мало, то многие, возможно, даже не слышали о подобных спорах. Ну а сейчас мы наблюдаем начало нового витка.
В настоящее время сформировались и обсуждаются два подхода к проблеме распараллеливания программ. Сторонники первого хотят получить какие-то средства, которые позволят им при минимальной переделке программы осуществить ее распараллеливание. Это практики, которые хотят приспособить свои решения к возможностям многоядерных систем, появляющихся на столах обыкновенных пользователей. Вторые любят поговорить о различных теориях распараллеливания, о языках параллельного программирования и том, что необходимо четко понимать, как будет работать параллельный код. Ведь, по их мнению, иначе невозможно достичь его корректности и эффективности.
Я согласен со второй группой, которая призывает к осознанным действиям, будь то отладка или эксперименты с использованием директив OpenMP. Такой подход провоцируют создание менее надежных программ, ведь работоспособным кодом признается не корректный код, а код, который корректно работает на ряде тестов. Это, безусловно, плохо. Но душой я полностью поддерживаю первую группу.
Я практик. И считаю, что уже давным-давно никто не знает, как работают реальные программы. И нет смысла говорить, понятна отлаживаемая или распараллеливаемая программа разработчику или нет. Она всегда непонятна, если мы говорим о промышленной разработке ПО. Противники «теории черного ящика» (первая группа) являются в основном представителями академических кругов, преподавателями или людьми, занимающихся решением узких задач, где важна крайняя эффективность параллельности. Например, численное программирование. Обычно они имеют дело с прототипами программ, которые что-то вычисляют, в которых они хорошо разбираются и знают, какие алгоритмы распараллеливания следует применять в каждом конкретном случае. Программы невелики, их можно прочитать или даже при необходимости переписать заново — на другом языке. Ошибка в том, что они пытаются масштабировать свой опыт на большие программные проекты.
Аналогия со второй группой (теоретики, или противники черного ящика). Человек с фонариком и лупой, который с интересом изучает красивый сундук, покрытый росписью и предлагает способы как сделать его еще более красивым и удобным в использовании.
Реальный программист, занимающийся развитием большого проекта, разрабатываемого годами или даже десятилетиями, находится в совершенно иных условиях. Скорее всего, он пришел в проект, когда уже написаны мегабайты кода и он не знает всю историю тех или иных архитектурных решений. Возможно, ему даже не у кого спросить. Он не имел времени прочитать исходные коды, и никогда не будет иметь столько времени. Он работает на определенном участке работ и может не представлять, как работают многие алгоритмы, написанные задолго до его прихода в группу разработки, но которые он вынужден использовать.
Аналогия с первой группой (практики, или сторонники черного ящика). Человек с фонариком и лупой в огромном лабиринте. Он может внимательно изучать фрески на стенах, но луч фонаря не может высветить противоположные стены и позволяет видеть коридоры лабиринта только фрагментами, не создавая целостной картины.
Я не считаю подход к параллельному программированию, как к эксперименту с черным ящиком, хорошей методологией. Но она лучше, чем не делать ничего или предлагать, полностью разобраться в структуре имеющегося программного комплекса и алгоритмов. Это, к сожалению, просто не получается. Сложность многих программных решений переросла возможности сознания отдельных людей и даже коллективов, которые с ними работают. Использование специализированных инструментов, которые позволяют как-то решить задачу распараллеливания и отладки является единственным доступным вариантом. Опыт разработки крайне эффективной, но маленькой параллельной программы здесь не применим.
Профайлер не предложит высокоуровневый способ изменения алгоритма. Но он покажет, как можно хотя бы частично ускорить программу, распараллелив наиболее критичные участки кода. Параллельный отладчик или анализатор кода не докажут корректность параллельной программы. Но они позволят подстраховать программиста, забывшего посветить фонариком в одном из направлений и тем самым упустившего от взгляда важный элемент.
Я поддерживаю методику использования инструментов, позволяющих и помогающих распараллелить не только хорошо понимаемый код, но и черные ящики, как практически единственный способ работы с большими программными системами.
комментарии (47)
Вот эсли бы визуализировать информацию!
И куда подевалось всеми расхваливаемое ООП? Куда подевались хорошо документированные интерфейсы и инварианты для модулей: мол ядро Linux'а — это то, что умеет делать fork, fork работает должен порождать процесс так-то и так-то, а детали реализации ядра Linux уже никому не нужны. Неужели в больших люди проектах не производят декомпозицию на модули?
Не можете. Потому что Вам нафиг надо и степень Ваших интересо заканчивается где-то на третьем-четвертом элементе списка. Если Вы — системщик, то она начинается на третьем-четвером и заканчивается на шестом-седьмом, если специалист по hardaware — начинается на седьмом и т.д.
Так какое у Вас есть право сказать «я полность понимаю как работает моя программа»?
Когда каждый программист большого проекта знает только свой кусок, это неизбежно приведёт к тому, что куски начнут дублировать функционал (велосипедизм), конфликтовать друг с другом и т.п.
Сама ваша статья очень интересная, поставил ей и вам плюсы, но при этом мне кажется, что вы путаете кислое с красным, когда аргументируете ваши соображения.
В идеальной программе – да. В реальной — нет. Устройство низкоуровневых модулей B и C может не рассчитано на параллельные вызовы. Достаточно наличие одной глобальной (общей) переменной в этих модулях и мы уже имеем дело с состоянием гонки.
Речь идет не только об успешных проектах
Во-первых, мы получили прерывания ввода/вывода, происходящие в непредсказуемые и невоспроизводимые моменты времени; в сравнении со старыми последовательными машинами, которые прикидывались полностью детерминированными автоматами, это разительное изменение, и преждевременная седина многих системных программистов служит свидетельством тому, что нам не стоит легкомысленно отзываться о логических проблемах, порожденных этой возможностью.
Так что вполне себе «давным-давно никто не знает, как работают реальные программы» :)
/me сторонник выкидывания мегабайтов старого трудноподдерживаемого кода и переписывания заново. Разумеется, если в этом действительно есть необходимость (не трогай работающую систему, да).
Вам не нравится, что я люблю писать с нуля? :)
У меня таких примеров тьма. Вот был заказчик, который хотел к битриксу прикрутить мааленький модуль. Сам битрикс в той ситуации заботился лишь за генерацию меню. Клиент был послан нафиг. Ну т.е. ему объяснили, что написать своё с помощью более другого фреймворка (фреймворк битрикс или cms — науке не известно. Известно только, что bloatware) будет стоить дешевле и закончится быстрее. Угадайте, что выбрал заказчик?
Вариант, когда меня берут в фирму поддерживать старый дремучий проект, в котором я буду заниматься маааленьким модулем и фиксом накопившихся за 100 лет багов, на которых взорвался мозг у нескольких поколений программистов, я рассматривать не буду. С такими ситуациями не знаком (и не познакомлюсь).
habrahabr.ru/company/intel/blog/78350/#comment_2290463
Инициативы Интела понятны, им же нужно оправдать выпуск многоядерных процов, поскольку наращивать частоту они уже не могут. А переходить на немейстримовые языки, которые хорошо параллелятся никто не спешит. Вот они решили сами вбросить, но пока их затея выглядет фантастической.
Какие языки использовать для написания софта под многоядерные процессоры? Да любые! Почему не спешать параллелить? Об этом, думаю, как раз и статья.
А насчет «решили сами вбросить» — я немного не понял.
Интел просто подходит только со своей стороны. Но пока это выглядет утопично. И для черных ящиков поднять производительность линейно все одно не смогут. Поэтому выход будет один — переписать, это трудно признавать, но это так. А вот если переписывать, то зачем брать С++, если есть более удобные языки для распараллеливания.
>Почему не спешать параллелить?
В интерпрайзе все инертно и никто никуда не торопится(а это основной рынок). Ждут-надеются на еще один усовершатор от Интела. Но все одно его эффективность будет во много меньше, чем код написанный с учетом ассинхронности на языке типа Эрланга.
+ не Интелом единым
Тут ситуация такая: мы (ИНтел) пытаемся работать в нескольких направлениях. Если говорить о «более удобных» языках, то по возможности мы контактируем с разработчиками, участвуем в выработке стандартов и т.п.
Да, я слышал множетсво комментариев в духе «вы большие, напишите параллельный питон или C#, что вам стоит?». К сожалению, это выглядит утопично. Нельзя сделать сразу все и всем. С этой точки зрения политика разумного вмешательства (или невмешательства, — это уж как удобнее) выглядит логично.
С++ — отдельная тема. Это та область, которая близка к enterprise рынку, как вы правильно заметили. Но в то же время эта та область, в которой у интел есть опыт. Поэтому я с трудом представляю что в одном из инструментов Интел не будет поддержки C++.
А еще я очень надеюсь, что когда-нибудь появится поддержка других языков :))))
В принципе, вы правы. Но писать многопоточную программу на java и на Erlang — это тоже самое, что сверлить буравчиком или дрелью. А если к примеру взять пролог (с правильным рантаймом), то там программисту не надо даже думать о многопоточности. Всё и так распаралелится. Другое дело что пролог хорош только для определённых задач.
Можно его резюмировать в 2-3 предложения?
Пеар, в общем.