Расширения для параллельной обработки (Parallel extensions) в .NET Framework. Нужны ли они нам? С этим мы разберемся в сегодняшней статье. Данная статья будет полезна разработчикам, работающим с программным обеспечением Microsoft. Также напоминаем, если вам необходимы услуги по независимому тестированию программного обеспечения, обращайтесь в компанию A1QA. Подробнее об этом ищите в блоге a1qa.
Microsoft Research и команда CLR team в Microsoft находятся на пути к победе со своими «Расширениями для параллельной обработки в .NET Framework (Parallel Extensions to the .NET Framework)», официально известными как библиотека Parallel FX. Цель Parallel Extensions — помочь специалистам по разработке программного обеспечения воспользоваться преимуществами мультипроцессорного/многоядерного аппаратного обеспечения, которое все в большей степени становится общепринятым для настольного компьютера и сервера.
Параллельный LINQ (Parallel Language Integrated Query — PLINQ), часть расширений для параллельной обработки Parallel Extensions, видимо, занимает большую часть площади страниц в мире блогов. PLINQ -расширение к языку интегрированных запросов LINQ, который стал доступным в .NET Framework 3.5. LINQ расплодил многочисленные расширения конвейерной обработки (pipeline extensions) с момента своего дебюта, некоторые из них доступны в CodePlex; например, Streaming LINQ (для обработки потоковых данных). Зачем нам нужны расширения для параллельной обработки Parallel Extensions в .NET Framework? Общее послание от Microsoft гласит:
• «Бесплатный обед закончен», закон Мура больше не выполняется.
• «Многоядерность — будущее для производительности и масштабируемости» (по крайней мере, согласно Intel).
Это, таким образом, приводит к простому уравнению: Параллелизм == Parallel Extensions для .NET Framework.
Журнал MSDN magazine уже опубликовал ряд статей, посвященных библиотеке Parallel FX (http:// msdn.microsoft.com/ru-ru/magazine/ccl63329.aspx), поэтому вместо того, чтобы механически повторять тот же самый код здесь, я дам оценку влияния Parallel Extensions с точки зрения проектов разработки программного обеспечения для инвестиционной деятельности банков. Оставляя в стороне бизнес-логику, многие приложения, связанные с инвестиционной деятельностью банков, живут или умирают в зависимости от производительности. Если технология может уменьшить задержку обработки потоков, то ее внедрение внутри банка произойдет быстро. PLINQ предлагает простой способ выполнения запросов в параллель. Обратной стороной (недостатком) этого является то, что код, который первоначально предназначен для выполнения в параллель, мог бы теперь вызвать появление нежелательного поведения, если бы не был тщательно протестирован.
В настоящее время большинство разработчиков программного обеспечения для банков не имеют мультипроцессорного/многоядерного аппаратного обеспечения, однако бизнес-партнеры банков (трейдеры/сбытчики) — имеют. Это несоответствие между аппаратным обеспечением разработчиков и используемым в производстве означает, что специалисты по программному обеспечению, пишущие код .NET, не могут быть уверены, что их приложение будет выполняться корректно, как только будет развернуто. Дополнением к этой заботе является тот факт, что аппаратное обеспечение, на котором выполняется тестирование, часто не отражает (свойств) производственного аппаратного обеспечения, что опять-таки означает, что ошибки, связанные с организацией поточной обработки, (и выявленные) в производстве не могут быть повторены на этапе разработки. Чтобы воспользоваться преимуществом новых подходов, важно для банков обеспечить, что их специалисты по программному обеспечению имеют соответствующее аппаратное и программное обеспечение перед принятием на вооружение Parallel Extensions.
PLINQ решает краткосрочную задачу предоставления разработчикам возможности воспользоваться преимуществом мультипроцессорного/многоядерного аппаратного обеспечения; однако PLINQ не исследует способ получения доступа к постоянно расширяющейся инфраструктуре compute grid, которую создают инвестиционные банки.
У Microsoft Research есть ответ на проблему PLINQ для распределенных вычислений — это DryadLINQ (http://research.microsoft.com/research/sv/DryadLINQ/). Dryad делает возможным надежные, распределенные вычисления на тысячах серверов для крупномасштабных приложений параллельной обработки данных. Microsoft AdCenter уже развертывает Dryad в действующей производственной системе. DryadLINQ позволяет приложениям параллельной обработки данных выполняться поверх распределенной вычислительной среды Dryad. К сожалению, в данное время DryadLINQ доступен только для внутреннего применения в Microsoft.
Принимая во внимание, что PLINQ прошел СТР в конце 2007 года, могли бы мы построить grid-вариант LINQ сегодня, чтобы начать пользоваться преимуществом compute grids? Если мы допустим для этого обсуждения, что собираемся использовать DigiPede (www.digipede.net) в качестве нашего решения распределенных вычислений, то могли бы разработать метод расширения С# 3.0, который направляет работу к этой сетке:
namespace Home.GridLinq
{
public static class GridEnumerable {
public static IEnumerable<T> OnGrid<T>( this IEnumerable<T> source)
{
// Передать работу для DigiPede (смотри http:mdavey.wordpress.com)
}
}
}
Используя метод расширения OnGrid, о котором упоминалось выше, мы могли бы затем оценивать клиентуру в параллель на сетке DigiPede: var prices=trades.OnGrid().Select(t => t.Price)
В предположении, что trades-это коллекция объектов класса Trade, которые следуют шаблону Digipede Worker (упорядочиваемому — Serializable), выражение LINQ, приведенное выше, эффективно переводит в последовательный режим объекты Trade за пределами compute grid, позволяя агентам Digipede выполнять ценообразование, а также возврат результатов обратно клиенту LINQ-приложения.
Где мы? Присутствуя в качестве гостя в финансовой вертикали, PLINQ не может быть реализован достаточно быстро. До тех пор пока банки понимают последствия, PLINQ будет улучшать экономический цикл. Microsoft, однако, нужно продолжать нажим в области параллелизма, облегчая жизнь разработчикам путем предоставления им доступа к ядрам локально, равно как и удаленно, а также путем обеспечения, чтобы инструменты разработки/отладчика не отставали от этой библиотеки по мере ее развития.
