Joe Duffy | Джо Даффи
Это пятый и последний пост из серии
«Великие люди параллельного программирования» . Мои читатели предложили мне длинный список других кандидатов в эту когорту гениев параллелизма и вполне возможно, что некоторое время спустя я продолжу этот цикл и возьму интервью и у других разработчиков тоже.
Ну, а на сегодня, моим гостем будет Джо Даффи – руководитель группы разработчиков Microsoft, которая занимается проблемами параллелизма в рамках CLR (Common Language Runtime, общеязыковая среда исполнения, если кто не знает). Сегодня Джо снова непосредственно работает с кодом, точнее говоря он разрабатывает библиотеки, инфраструктуру и программные модели поддержки параллелизма. Формально он работает в рамках Microsoft’s Developer Division. Поэтому не удивительно, что я решил поговорить именно с Джо Даффи о потоках в рамках платформы .NET, тем более что в интернете этот человек уже давно известен благодаря своему
блогу, посвящённому параллельному программированию, и своей книге —
Professional .NET Framework 2.0. Я благодарен этому человеку за то, что он согласился ответить на мои вопросы !
И так первые 5 вопросов посвящены параллельному программированию вообщем:
Майкл: Наступает эра многоядерных процессоров, как вы думаете, Джо, как это отразиться на области параллельных вычислений, станет ли, наконец, параллельное программирование частью мейнстрима? Или же это просто ещё один этап на пути использования параллелизма и вскоре интерес к параллельному программированию вновь будут проявлять только люди, занимающиеся высокопроизводительными вычислениями (HPC — high performance community)?
Джо: Сейчас нельзя точно сказать как оно там будет в будущем… и когда же наконец параллельное программирование станет частью мейнстрима. Рост производительности безусловно важен для многих людей (но не для всех) и фактически рост производительности будет способствовать росту продаж ПК (что косвенно повлечет и рост продаж коммерческого ПО). И в этом смысле параллелизм безусловно станет мейнстримом. Но только это вовсе не означает, что каждый программист прям с завтрашнего дня начнёт заботиться о распараллеливании программ, которые он создает, и вообще будет больше думать о параллелизме в процессе разработки.
При этом, однако, большинство разработчиков ПО сегодня не смогут запросто овладеть параллелизмом и работать с ним – сегодня написание параллельного кода это очень непростая задача (если к тому же учитывать те технологии, которые повсеместно сегодня используются разработчиками). Более того, большинство разработчиков просто не представляют куда теперь девать всю вычислительную мощь многоядерных процессоров, которые постепенно заполоняют десктопные машины пользователей. Небольшая кучка истинных приверженцев параллельного программирования научится-таки решать задачи пользователей, используя всю мощь нескольких ядер, именно эти «выскочки-отщепенцы» заработаю свои миллионы и покажут нам всем как нужно программировать и как нужно решать задачи, используя параллелизм. И вот тогда-то можно будет сказать, что параллелизм вошел в мейнстрим программирования. Но на данный момент об этом ещё рано говорить.
Майкл: Время от времени в сети разгораются споры – что лучше для параллельного программирования – программирование в системе с общей, разделяемой памятью(shared-memory programming) или же программирование через посылку сообщений(message passing). Каково ваше мнение на этот счёт?
Джо: Моё мнение таково – реально между взаимодействием через общую память и между взаимодействием через посылку сообщений нет практически никакой разницы. В чем отличие отправки\принятия сообщения и разветвления\объединения(forking\joining) при параллелизме по данным ? Логически это вполне себе похожие вещи, различающиеся разве что в специфике управления данными, доступом и коммуникациями. При этом с точки зрения параллелизма вы точно также должны думать о зависимостях, причинной обусловленности, компонуемости, ошибкоустойчивости и т.д. Системы с общей памятью не способны одномоментно решить все эти важные (и сложные) задачи.
Для меня важным является другой вопрос – каким образом мы можем объединить эти два мира ? Каким образом мы можем перенести такие свойства систем посылки сообщений как атомарность и изолированность на те конструкции программирования, которыми сегодня постоянно пользуются программисты? (Или, другими словами, какие же языки программирования люди должны использовать при параллельном программировании, если мы не можем изменить те языки, которые используются сегодня?). Системы взаимодействия на основе посылки сообщения являются особенными, в том смысле, что они под час изначально создаются с учётом этих вопросов. Я полностью уверен, что неизменяемость(immutability) и изолированность (локальность) – это два столпа, на которых должны основываться (или хотя бы должны их поддерживать) все современные системы типов, даже если эти системы типов предполагается использовать в императивных языках, системах с разделяемой памятью, языках семейства Си. Правда несколько (немного) таких примеров уже есть.
Майкл: Хорошо. Отметьте, пожалуйста, самые выдающиеся, на ваш взгляд, достижения\инновации в области параллельного программирования за прошедшие несколько лет.
Джо: Во-первых, нужно отметить гигантский объем проделанной работы в области верификации программ, новых механизмов синхронизации (нпр., системы на основе транзакционного доступа к памяти), а также новых способов описания мелкозернистого параллелизма (примером такого типа параллелизма является параллелизм по данным). Кроме систем поддержки транзакционного доступа к памяти можно ещё отметить Fortressm, X10 и Chapel (прим.перев. [извините, не сдержался] — а я бы ещё отметил наш ответ IBM’овскому X10 – язык
MC# ). В сообществе Haskell программистов проделывают классные штучки с параллелизмом по данным. Обратите внимание на язык NESL и его идею вложенного параллелизма (Nested data parallelism). Вообщем я вижу кучу крайней интересных идей и их реализаций.
Майкл: Каким вы видите будущее параллельного программирования? Что вы можете предложить в качестве серебряной пули в этой области разработки?
Джо: Я не верю в существование каких-либо серебряных пуль в области параллельного программирования. Посмотри на аппаратную поддержку параллелизма – объединяя различные технологии параллелизма на уровне [машинных] команд (ILP: нпр., супер скалярные процессоры, предсказание условного перехода, конвейеризация) мы добиваемся прироста производительности, причём тут нет никакой магии — мы можем спрогнозировать величину этого прироста при использовании той или иной комбинации ILP-методов распараллеливания. Я думаю, что дела будут обстоять подобным образом и в программировании ПО. Мы будем использовать высокоуровневые механизмы для программ, в которых мы можем выделить большие куски независимой функциональности, которую можно легко распараллелить (возможно даже изолированно); более низкоуровневые механизмы для распараллеливания логически независимых активностей; и, наконец, мелкозернистый параллелизм (параллелизм на уровне данных или на уровне задач) — для того чтоб распараллелить конкретные участки кода, из которых состоят активности уровнем выше. Причём подобным образом мы будем поступать на всех уровнях абстракции, начиная от библиотек и заканчивая языками программирования и средами исполнения.
Майкл: На сегодняшний день, одной из главных проблем параллельного программирования является то, что оно несколько сложнее последовательного. Продуктивность кодирования при этом резко отличается, от последовательного программирования. Как вы думаете, существуют ли способы, способные изменить такое положение дел?
Джо: Собственно это всегда так происходило и происходит – всегда что-то новое кажется для некоторых программистов сложным, но я уверен, что мы сможем достигнуть значительных успехов за счёт абстрагирования. И на определённом уровне абстракции параллельное программирование будет доступно большинству программистов. На самом деле при использовании параллелизма просто возникают дополнительные вопросы на этапе проектирования и реализации, но автомат, описывающий программу становиться конечно чрезвычайно сложным. На самом деле программисты должны осознавать существование тех или иных зависимостей в своём коде и проектировать свои программы, обеспечивая более низкое зацепление модулей и более слабые зависимости по данным. Думаю со временем всё утрясется.
--
Это была первая часть интервью. Следующая посвящена, собственно, потокам в .NET:
Майкл: В чём вы видите сильные и слабые стороны потоков в .NET по сравнению с другими системами параллельного программирования ? Что бы вы хотели улучшить ?
Джо: Сила .NET-потоков заключается в многообразии готовых, оттестированных базовых элементов, которые программист может использовать для создания сущностей других уровней абстракции. Главным же недостатком является то, что можно перечислить большое число полезнейших абстракций, которые хотелось бы иметь в базовой библиотеке .NET для работы с потоками, но их нет.
Майкл: Если бы вы сегодня проектировали потоки в .NET с нуля, чтобы вы сделали по-другому?
Джо: Ну, трудно сказать, понятно, что мы могли реализовать потоки в .NET по-другому, но полёт нашей мысли постоянно наталкивался на ограничения( в плане поддержки параллелизма) самого .NET Framework, а также Win32 API. Нам пришлось отталкиваться от разделяемой памяти, изменяемых(mutable) переменных и прочих тонких деталей и опасностей платформы. Можно по пальцам пересчитать людей, которые полностью понимают причины и особенности этих проблем… эти люди должны были либо научить остальных разработчиков(поделиться сокровенным знанием), либо создать для остальных более высокий уровень абстракции, спрятав за ним необходимость работы с тонкими местами платформы. Я конечно же уверен, что мы могли сделать все гораздо лучше, если бы параллелизм был заложен в платформу со дня её основания. Мы работали в мире, где на протяжении 20+ лет властвовало «одноядерное мышление» и этого нельзя не учитывать.
Майкл: Можете ли вы порекомендовать какой-либо инструментарий для людей, использующих потоки в .NET. Может быть IDE? Редакторы? Отладчики? Профайлеры? Верификаторы? Ещё что-нибудь…
Джо: Visual Studio вполне хороший инструмент для отладки многопоточного кода, а WinDbg позволяет наблюдать низкоуровневые структуры данных ОС (в частности связанные с многопоточностью). Профайлер, который идёт в месте с Visual Studio 2005 также может быть полезен, если вы хотите знать куда деваются тики ядер вашего процессора, кроме того разнообразные счетчики позволяют узнать, например, количество промахов в кэше второго уровня и т.д. Можно посоветовать использовать Intel VTune и сопутствующий инструментарий для анализе взаимодействий в многопоточном коде, хотя инструменты Intel работают в рамках .NET с некоторыми ограничениями.
Майкл: Пожалуйста, дайте совет тем, кто только начинает использовать потоки в .NET. С чего бы вы начали сами? Может быть книги? Уроки? Интернет ресурсы? Где, то самое место, где можно найти ответы на все вопросы?
Джо: Думаю стоит почитать
мой блог, а также блоги
Криса Брумма и
Ванса Моррисона. На сайте MSDN’а есть хорошая
подборка статей по этой теме . Ну и конечно, не пропустите выход моей новой книги — Concurrent Programming on Windows.
Майкл: Самая ужасная ошибка, с которой вы когда-либо сталкивались в программе, использующей .NET-потоки ?
Джо: Многопоточность в .NET — это
достаточно низкоуровневый инструмент для написания параллельных программ. Люди часто испытывают проблемы с гонками и дедлоками, надёжностью, неожидаемой реентерабельностью, с GUI, с таким понятием как thread affinity и прочими вещами. В моём блоге есть
обзор наиболее частых ошибок программистов, который может быть полезен и интересен .
Майкл: Большое спасибо за интервью!
