Побочные эффекты распараллеливания
Сейчас я скажу о том, что все знают и о чем говорят уже несколько лет. Параллельное программирование неизбежно. Я знаю, что прозвучало это банально! Но я специально выделил это в отдельный маленький пост, в надежде кто-то задумается над этой простой фразой чуть дольше. Часто то, о чем мы регулярно слышим, теряет всякий для нас смысл и не приводит к размышлениям и выводам. Попробуем же сделать несколько этих выводов.
Когда мы слышим о параллельном программировании и преимуществах, которые оно дает, мы сразу ассоциируем это с тематикой роста количества ядер на кристалле и о возможном приросте производительности приложений. Еще при этом мы вспоминаем о технологиях параллельного программирования (MPI, POSIX Threads, OpenMP) и инструментах.
Я подскажу два других направления мысли, которые могут быть гораздо полезнее. Одно полезнее всего программистам, второе менеджерам проектов.
Специалистов, способных писать параллельные программы и имеющих соответствующий опыт, крайне мало. В ближайшее время можно ожидать кризис кадров в этой области. То, что в институтах сейчас массово вводятся курсы по параллельному программированию, не в счет. Конечно, это увеличит количество специалистов, но не значительно и очень постепенно. Как всегда только несколько человек в группе будут понимать, о чем речь и изучать это, остальные просто «прослушают курс лекций». Таким образом, быстро увеличить количество программистов за счет введения новых курсов не получится.
Определенным опытом параллельного программирования обладают люди в академических кругах. Не хочется обидеть этих людей. Действительно, часто можно встретить высококвалифицированных разработчиков создающих параллельные системы и разбирающихся в предметной области, для которых эти системы предназначены. Но их навыки чаще всего не сочетаются с промышленной разработкой ПО. Я не знаю чем это вызвано. Но в нашей стране разработка академических программных проектов и прикладного программного обеспечения для пользователей, это как бы две совершенно разных области. Можно дискутировать на эту тему, но не хочется. Считайте это просто моим ничем неподкрепленным мнением.
Отсюда можно сделать первый вывод. Скоро можно будет быстро подняться по карьерной лестнице в сфере программирования, если заранее изучить область параллельности. Поскольку свободных специалистов почти не будет, то в новых проектах можно стать лидером группы. И в любом случае специалисты в области параллельности будут в цене, и за ними откроется настоящая охота!
В связи со сменой технологии программирования, произойдет перераспределения рынка некоторых решений. Будут области, где основные производители упустят из вида актуальность адаптации своей продукции для параллельных систем. Для ряда клиентов это критично, и они будут вынуждены искать альтернативные решения. Это удачный момент выхода на рынок с новым решением или просто возможность забрать себе клиентов у неповоротливых компаний.
Поэтому второй вывод — менеджерам проектов разумно проанализировать, как освоение параллельности может помочь повысить конкурентоспособность их решений. И именно с точки зрения конкурентоспособности в кратко- и долгосрочной перспективе преподнести свои услуги заказчику.
На этом все. Надеюсь, кто-то продолжит в голове у себя эти рассуждения и найдет полезное зерно. Уверен — мысль может пойти и по другим маршрутам. Удачных размышлений! :)
комментарии (84)
Лет 10 назад когда многие юные программисты делали все раздельные компоненты в разных тредах — процессорам на это было совершенно параллельно.
Потом звук как стандарт дефакто переполз в свой тред.
После, в начале эпохи двуядерности, туда же ушла и физика и видео конвертеры.
Сейчас тренды другие — не параллельность задачь, а параллельность исполнения их алгоритмов.
И, имхо, лабы про мьютексы в виде перекрестка дорог — это старое программирование.
В новом все сложнее, только вот как… лично я пока не знаю.
Так в чом мы тут говорим — о банальном разбивании програмы на блоки и обучении этих блоков работать асинхронно, или о тех красивостях что дает OpenMP и другие CUDA\OpenCL( имхо мы же в параллели на нескольких сотнях ядер считаем )
Если последнее — сотрите упоминание по pthreads :)
А если первое — сотрите OpenMP
эти две философии живут в параллельных мирах
пс: и я очень надеюсь что я везде написал правильное количество «лл»
Вот посмотрите — когда десятки (или сотни) клиентов одновременно обращаются к сайту, а точнее, к одному скрипту. Хостеры (а точнее демоны apache или ngnix) запускают кучу процессов выполнения PHP-скриптов. Причём, как устроено это внутри — не важно (процессы, нити, диспетчеризация в одном ядре, по нескольким ядрам, на разных серверах).
Главное — понимать, что распределение работ осуществляется на нижнем уровне. А проблема разработчика — обеспечить работу своих скриптов таким образом, чтобы их параллельная работа не нарушала исходного алгоритма. Например, за счёт использования БД. Либо за счёт файлов-флагов.
Статья, конечно, правильная для «системщиков» типа Игоря Сысоева (разработчика ngnix-a), но таких единицы. А для остальных особо ничего не изменится. Просто весь софт постепенно перейдёт в интранет/интернет.
это просто набор «програмок» которые исполняют различные задания для различных людей, и, по хорошему, полностью изолированные друг от друга.
Вопросы же поднимаемые в данном топике касаются решения ОДНОЙ задачи и одной цели несколькими мозгами.
Тоесть ровно обратная задача :)
И нгинкс кстати не параллельный — он асинхронный( воркеры не всчет)
Может быть есть одновременность выполнения, что создает иллюзию параллельности. Как же это сказать то правильно… интуитивно представляю, а словами не могу :(
Понимаете, скрипты выполняются одновременно (и как-бы параллельно, но только для наблюдателя), но выполняют разные завершенные задачи. Например добавляют сообщения в гостевую книгу.
Насколько я понимаю параллельность (википедию не читал ;) ) — это… давайте я аналогию приведу лучше?
Выполнение двух скриптов на вебсайте — это 2 кастрюли супа. Они действительно варятся одновременно, но это не параллельность. Параллельность — это когда повар варит бульон, параллельно с этим делает поджарку для супа, и пока лучок с морковочкой в маслице жарится, повар чистит картошечку.
P.S. Надеюсь, мои аналогии не покажутся наивными для гуру ;)
Даже извлечение корня и вычисление числа Пи можно разложить в ряды, части которых считать на разных процессорах (или в разных потоках). Тогда снова получается, отличий от банальных скриптов PHP нет.
Ну а гидродинамика, обтекание самолётов, поиск месторождений нефти (что раньше считали на транспьютерах — таких истинно-параллельных машинах) — это ещё легче распараллелить алгоритмически.
Но если развить мысль дальше, можно на автомате и параллельные участки кода выявлять. Да, будет какой-то суперфиндиперсовый анализ графов, но результат того стоит.
Может, за этим будущее?
В частности, такой позиции придерживается Дональд Кнут:
То есть да, выполнение различных по функциональному наполнению модулей на разных ядрах — это приятно.
А вот задач, где нужны именно параллельные алгоритмы (мы же про OpenMP тут, и иже с ними?), ну их же реально не так много.
> будет предложен альтернативный путь
Альтернативный путь чего? Дальнейшего истязания закона Мура?
Закон Мура — это же просто маркетинг, с него вполне можно пересесть на что-либо ещё.
Вот почему-то мощность автомобилей не растёт почти совсем, но чего-то не слышно плача и выкриков «О! Автомобильная индустрия зашла в тупик! Надо искать выход!»
Тихонько фигачат себе, и всё.
Производителей железа постигнет та же участь. Рано или поздно.
Вот лично меня всё устраивает в моём настольном Семпроне-1800 с 512 метрами.
Это правда, если вы говорите про ВАЗ.
«Energy in Transport
Trends and Influencing Factors
2006 Report»
Буду изучать и авторитетно отвечу тогда
Вы себе представляете таксиста на 600 сильном тарантасе, или бабушку отправлющуюся за покупками на реактивном автомобиле?
Есть порог разумности. В городе, на трассе, и даже на автобане не всем нужно нестись 300-400, разгонятся и тормозить с перегрузкой как в истребителе.
Правда для компьютеров пока ещё придумают чем озадачить ресурсы :)
Ну, ещё с D можно поковыряться, только сейчас там синтаксис неопрятный…
2**(123.to_s.reverse.to_i)
Угадайте, что делает?
Хотя D конечно намного, НАМНОГО лучше чем perl.
100.times{ puts rand }
или
(9..17).to_a.inject(0){|summ,i| summ+3**i}
выведет 193700403
Паралельность нужна, когда нужно производить много вычислений (зачастую однотипных), тогда компилятор олжен понимать, как надо разбить вычисления нанезависимые части (в идеале, зависимые) чтобы считать их в разных потоках.
www.keldysh.ru/dvm/dvmhtm1107/rus/dvmINTRr.html#3%20%D0%A1%D0%BE%D1%81%D1%82%D0%B0%D0%B2%20DVM-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B
Программы на Фортране и Си автоматически распараллеливаются.
Пример для расспаралеливания подобран очень неудачно, так как раз это тот пример который и так уже достаточно хорошо проработан и оптимизируется автоматически лучше чем это сделает большинство програмистов.
х86 архитектура не самая удачная для таких задач, компилятор для Итаниума для такого кода может сгенерировать сразу код для загрузки конвеера, а учитывая что это VLIW, то там и плотность инструкий выше, а конвеер проще.
А теперь представьте что в рамках одной архитектуры P3, P4 и Core 2 Duo и даже в рамках одного поколения но с кристалами с разными кешами этот код будет исполнятся по разному. Вы всё ещё хотите что-то вроде VHDL, а готовы оптимизировать под все наличествующие на рынке семейства процесоров, а также после поставки на рынок обновлять для новых. Во сколько вам такая разработка вольётся?
Я считаю что оптимизации такого рода должен делать по большей мере компилятор или возможна или какой-то рантайм с оптимизацией по мере исполнения, Profile-Guided-Optimization пока не расскрыл весь свой потенциал, да и JVM, .NET JIT можно в этом направлении оптимизировать.
А если посмотреть на типичный софт, то действует как всегда принцып Паретто, 10% функций исполняются 90% времени, а остальное ждёт окончания. Те 10% в большинстве случаев оптимизируются неплохо и существующими методами.
Я так понимаю на большей частоте издержки на схемы синхронизации превышают все разумные значения.
Вспомните из личных задач сколько из них не решаются имеющимися средствами. Игры — для ных созданы графические ускорители. Для остальных повседневных задач домашнего пользователя 4 ядра пока будет достаточно. Я понимаю маркетинг каке-то время превознесёт перекодирование в AVC за надцать секунд на 50 ядерном процесоре, но будет ли готов потребитель платить за это?
Закон Мура домашнему пользователю не нужен, потому что потребности домашнего пользователя не растут по этому закону.
Остаются нучная сфера и корпорации, но и там, часто применение специализированого ускорителя даёт больший результат, чем сотни универсальных вычислителей с КПД для даной задачи менее 10%. В Веб параллелизм на уровне процесов, который достаточно хорошо работает в рамках существующих парадигм простым добавлением ядер и памяти, здесь больше играет архитектура компютерных систем, иерархия памяти, арбитраж доступа к ней, пропускная способность, латентность, системы ввода-вывода.
Так же и с компьютерами — были бы 50 ядер, а применение найдется.
3D лучше работает на специализированных видеоускорителях, а там уже и так >50 ядер. Тот факт что приставочный бизнес приносит больше прибыли привёл к тому что изза игрушек стали меньше покупать ПК, а современные масовые игрушки стали менее требовательны, потому что уровень приставок отстал от уровня видеоускорителей.
Если же говорить об исходной теме статьи. То не будет масового предложения работы паралелистам, просто потому что не может быть много хороших паралеллистов, алгоритмистов и математиков. Их нужно достаточно чтобы написать достаточно хороших оптимизированных библиотек Intel Performance Primitives, OpenCV, оптимизированные компиляторы, а остальная маса будет использовать иногда правильно, иногда нет ихние наработки.
Вы хотите по сути искусственный интелект и увязываете его с паралелизмом. К сожалению я не вижу возможности для какого-то особого прорыва в этой области, только решение частных задач. Многоядерность здесь вообще слабо увязывается, да некоторые задачи можно распаралеллить, но невозможно расспаралелить то для чего не придумано алгоритмов. Гугл, Майкрософт и компании помельче работают над этими задачами, но кроме частных решений я не верю в радикальный прорыв в ближайшем будущем. Более того я думаю более ресурсо'мкие приложения будуть исполнятся в специализированніх облаках, а пользователь будет получать только результаты.
Насчёт фильмов, такой проблемы нет если изначально иформация имеет метаинформацию. Так или иначе ваша свалка фильмов это пережатые варианты чего-то что уже существует с этой иформацией. Решений для вашей проблемы скорее всего и не будет, потому что фильмы то пиратские, а следовательно на вас денег не заработаешь. Если брать тот же iTunes, Miro при помещении в каталог добавляют необходимую метаинформацию. Можно конечно придумать задачу, найти сколько в секундах в определённом фильме и в каких нарядах появлялась Одри Хепбэрн, а также проставить метки для быстрого перехода к эпизодам, но только насколько нужно это будет пользователю, готов ли он будет оплатить трудозатраты на это и почему он не может то же получить с облака например на свой мобильный?
Моя идея такова, что каждое новое ядро даёт всё меньше полезного действия пользователю и уже скоро будет излишним. Готов ли он будет оплатить миллиардные затраты Интела и АМД?
> распознаванием оно станет, когда будет находить Васю Пупкина на всех имеющихся фотках
Насчет конкретно Пупкина не знаю, но Picasa вполне достоверно распознает лица. Путем последовательного приближения конечно, и не без вмешательства пользователя, но — функционал рабочий и довольно удобный. Сам проверял на архиве из десятка гигабайт фотографий.
Ребята из Гугла хорошо вложились в Picasa, и «распараллелена» она — любо-дорого посмотреть.
Они не в состоянии не из за технологической невозможности, а изза отсутствия универсального алгоритма. И таковой вряд-ли появится в обозримом будущем.
кстати — тут уже было обсуждение технологий
Иммутабельность и чистота не являются необходимыми, но учат писать независимые потоки без синхронизаций.
Erlang, Haskell,…
Многопоточные системы пишут уже давно (Erlang), просто не везде, так что технологии есть.
VHDL выбран как не самый удачный прототип, к тому же не самый расспространённый.
Вообще-то в мейнстрим возвращаются функциональные языки(.NET F#, JVM Scala) и я уверен что основные движения будут именно здесь.
Ключевая фраза в высказываниях Кнута:
Он требует это( и распальцовку еще, также как и vim) от пользователя.
— Opera 10.50 — снова самый быстрый браузер
— Новое поколение nVidia ION
— johnny-cache — кэширование SQL-запросов
— Нынче ночью состоялся запуск ещё трёх космических аппаратов Глобальной навигационной спутниковой системы (ГЛОНАСС)
— Электроника в болидах Формулы 1
Так о чем это я… Есть такое мнение, что производительность — вторична, а функционал — первичен.
Андрей, а покажите нам класс? Попробуйте «продать» Хабрапользователям каждый из этих проектов, «с точки зрения повышения конкурентоспособности». Мы все — как бы заказчики. Вы — подрядчик, в совершенстве владеющий методами параллельного программирования.
Какой выигрыш мы получим в этих «проектах» от распараллеливания?
Уважаемые Хабрапользователи! Предлагаю голосовать за каждую попытку «продажи»: плюс — убедил покупаю, минус — не впечатляет, не покупаю ;)
Помните, «принимать пищу в столовой, а работать в кабинете» и всё такое прочее?
Вот я и думаю, что видео надо смотреть на телевизоре, звонит по телефону, а компилировать — на рабочем компьютере.
То есть специализация сделает решение конкретных задач гораздо более комфортным.
Автомобильная аналогия, опять же. Есть смарты, есть трактора. Они для разного, и каждый делает своё дело хорошо. Пользователи довольны и пляшут, маркетологи диверсифицировали рынок, инженеры работают не над одной универсальной моделью, а над несколькими специализированными, то есть работы для специалистов больше. Мечта прямо. И переписывать все-все программистские книжки не надо.
Если разработчики плеера (программного плеера или flash-плеера) не поднимают сами себе приоритет, то ничего тут не поделать. Для программных плееров есть например reclock, который умеет повышать автоматом приоритет. Есть также Prio, который умеет сохранять приоритет для заданного приложения. Но во для флэш-плеера придумать нечего, только лишь поднять приоритет всего браузера/опустить остального.
И никакой восьмиядерник тут не поможет, если в фоне будет рендериться что-то на всех 8ми ядрах.
Отдавать максимальный приоритет тому приложению с которым в данный момент работает пользователь, а на другие приложения то что останется, и делать это автоматически на уровне операционки(ну или околоОСного окружения).
Вот например у меня что-то где-то компилируется, а я тем временем сижу в ворде. Вот нафиг мне нужны все эти тормжения ворда, и замерзания интерфейса? Мне главное чтобы в данный момент максимально эффективно работал ворд, и чтобы ничего мне не мешало… Теперь допустим, я что-то в нем попечатал и переключился на окошко компилятором, где бегут веселые(или не очень) строчки. И естественно что сейчас меня интересует именно компилятор, а этот ворд пускай себе на заднем фоне тормозит сколько влезет, заодно со всеми браузерами, аськами, антивирусами и вирусами — все равно я их видеть не вижу и не желаю(покрайней мере сейчас). Надоело мне смотреть на компилятор, запустил плеер — и смотрю кино — и опять мне нужно чтобы работало то окно на которое я щас пялюсь, а все остальное не должно мне мешать.
Если кто-то лучше понимает почему это не так — расскажите плиз, и что мешает разработчикам ОСей это реализовать — ведь идея лежит на поверхности, но нигде нет (покрайней мере из тех что я знаю).
Немного про эфективность:
Если в однин поток время счета t_1, в 2 — t_2, ..., в N потоков t_N
И если рассматривать величину a_N = t_1 / t_N (во сколько раз уменьшилось время счета) и сравнивать с N, то получается печальная картина. Хорошо если a_N/N ~ C*N, бывает что и вообще стремится к нулю. А в случае ~ C*N, бывает C ~ 0.1, или и того меньше. Так что паралельное программирование не так уж и вторична.
То же самое, что говорить о распараллеливании при постановке задачи «запускать демоном или по крону» — тут достаточно много решений, основное — это блокировка сущности в общей БД, а там работа по принципу — кто первый встал, того и тапочки.
на более бытовом уровне — у меня есть сервис (web-сервис), обслуживающий запросы
если он нормально написан (атомарен), то чтобы получить прирост от многоядерности, я тупо увеличиваю в настройках количество рабочих процессов, в которых он крутится, и они расходятся по разным ядрам
все.
навыки параллельного программирования здесь если и нужны, то минимальные
и такая ситуация в 90% задач
имхо достаточно иметь базовое представление о правилах проектирования приложений и систем, которое позволит при необходимости наращивать производительность критичных элементов путем настроек исполняющей среды, а не переписывая код
будет ли это отдельное ядро или отдельный сервер — дело десятое…
В этом году, среди третьекурсников (распределение по кафедрам после второго курса происходит) уже половина занимается паралельным программированием, при этом технолгии используются совершенно разные:
CUDA — неплохой прирост в производительности дают видеокарты, так как там много «маленьких ядер», каждый из которых может взять на себя маленький поток вычислений. В механических задачах, обычно строится какая-то вычислительная модель, основные действия в которой это стандартные сложение, вычитание, умножение и деление, поэтому CUDA замечательно подходит. В ИПМ (Институт прикладной математики им. Келдыша) вроде собираются строить супер(супер компьютер) на основе fermi.
Какая-то система от Intel, позволяющая паралелить программы на «домашнем» многоядерном процессоре. К сожалению не помню специфики.
Система, которой занимаюсь в том числе и я, позволяющая упросить написание паралельных программ, сейчас проходит обкатку на суперах (пока правда маленьких в ИПМ, но результаты выражают оптимизм). Может когда-нибудь выйдем на МГУ-шного «Ломоносова».
Конечно, есть люди использующие MPI, но есть мнение, что в нем используется много накладных расходов, при увеличении числа вычислительных узлов.
Так что я с оптимизмом смотрю в будущее и думаю, что специалисты по паралельному програмированию будут нивелированны средствами разработки и опытом молодого поколения.
Имхо сетевые мьютексы, отказы нод, асихроные ожидания — это вам не #pragma omp pallalel for и поехали
И RPC с корбами тут не спасет
RPC то же сколькая тема, к сожалению 90% существующих RPC систем малоприменнимы в том виде, в котором они есть.
И все равно, имея RPC программисту придется возиться со всеми синхронизациями, делая нудную, однообразную, плохоподдающуюся автоматизации работу.
Хотя для своих задач — очень удобна.
В два клика прокинуть полный функционал класса в другой язык, да еще и с другой машины.
Если посмотреть, например, на PyRo то там вообще какой-то праздник, в части rpc, посмотрите минимальный пример здесь
Только не надо «ручками» интерфейсные классы поднимать.
И не надо никаких rmiregistry запускать на каждой машине (как это сделано в RMI в java), не надо описывать интерфейс класса как в большинстве RPC. Все просто и красиво. А главное работает, сходу без многочасового шаманства.
«Вах смотри какая сказка, чтоб завтра в общем работало!»
И использовали ее потому что функционал который надо было викинуть в инет, да еще и в солярис работал только под виндами, на дельфях…
Ну зачем же переписывать, мы так старались..
Некоторые решения, казалось бы разумных RPC, просто убивали: в Zeroc ICE, например, нельзя передать массив. Просто нельзя. Только контейнер или в виде связного списка.
А теперь берем пользовательское программное решение под Win32… там даже никто никогда и не задумывался, над таким словом как параллельность! Да, там могут быть потоки, например для фоновой отрисовки прогрессбара. Но это совсем иное. И адаптация подобных программ — терра инкогнито.
При этом адаптация бытовых приложений может быть сложнее, чем усовершенствование некой системы численного моделирования. Архитектура пакета численного моделирования изначально рассчитывается с учетом параллельности. А в обыкновенных приложениях, там не только черти ноги ломать будут. :)
habrahabr.ru/company/intel/blog/85645/
Что делает пользователь обычно своей массе — смотрит/слушает/играет/пишет.
В играх этот тред уже давно, как писали выше.
Паралелить текстовые процессоры и программы создания презентаций? Они и так шустро летают, и тут каких-то сверхгигантских суперзадач нет.
Самые подходящие жертвы для распаралеливание это графические пакеты, музыкальные пакеты.
А там давно и старательно борятся за производительность, и они такой тренд не упустят.
Вобщем имхо, всё и так идёт как надо, а паралелить ворд я смысла не вижу — я не могу сразу 10 документов набирать — пусть себе в фоне орфографию проверяет и прогресс бары рисует многопоточно. Не надо увлекатся выше меры и преувеличивать важность этого дела :)
Мир программирования давно уже стал коньюктурно оиентированным. Это означает что активным спросом на рынке пользуются те специалисты которые хорошо разбираются в абсолютно попсовых вещах типа .net.
С другой стороны рынок потребляет популярные технологии, которые обеспечиваются поддержкой массового количества специалистов с рынка труда.
С третьей стороны список задач который стоит перед массовым потребителем ПО перекрывается технологиями десяти или двадцатилетней давности. Всё остальное в большинстве своем маркетинг и рюши.
С четвёртой стороны массовое внедрение технологий происходит только после того как компании выпустят средства разработки под эти технологии.
Резюме — внедрение технологий, например, парралельного программирования, будет возможно только при наличие профинансированных задач и при условии массового восприятия этих технологий разработчиками
Места в секретных лабораториях уже заняты. И надолго. Так что боятся не надо. Надо ли изучать новые технологии? Да. Потому что этого дребует профессиональная этика любого инженера или разработчика.