В C# 5.0 часть возможностей этой библиотеки перекрывают две новые конструкции: async и await, с помощью которых задается запуск параллельных (асинхронных) потоков и ожидание завершения их работы, соответственно. Вот характерный пример их использования:

public static void Main(string[] args)
{        .   .   .
   while (true)
   {
     Console.WriteLine("Please input a number");
     number = int.Parse(Console.ReadLine());
     DoSum(1, number);
   }
}

public static async void DoSum(int from, int to)
{
   int result = await Sum(from, to);
   File.AppendAllText( ... result ...));
}

public static async Task<int> Sum(int from, int to)
{
 Task<int> sum = TaskEx.Run(() =>
 {
   int result = 0;
   for (int i = from; i <= to; i++)
   {
    // Simulate process delay.
    Thread.Sleep(500);
    result += i;
   }
   return result;
 });

 return await sum;
}

Здесь, в главной программе запускается несколько асинхронных (параллельных) потоков DoSum, которые, в свою очередь, запускают дочерние асинхронные потоки Sum. Наконец, внутри Sum запускаются еще, на этот раз, безымянные потоки (в виде объектов типа Task).

Для иллюстративного примера такая тройная вложенность не очень хороша − можно было бы придумать что-нибудь и попроще, но нас в этом фрагменте будет интересовать другое, а именно, типы используемых выражений.

В частности, обратим внимание на присваивание

int result = await Sum(from, to);

В корректной программе, типы правой и левой частей любого присваивания должны совпадать.
Т.е., мы ожидаем, что выражение

await Sum(from, to);

имеет тип int. Поскольку await есть просто оператор ожидания завершения работы (асинхронной) функции Sum, то разумно предположить, что эта функция должна возвращать int. Смотрим в определение этой функции и
видим, что тип возвращаемого ею значения есть Task<int> − однако, думаем мы сами про себя!
Ладно, попробуем исправить ситуацию и предположим такое действие оператора await: если его аргумент имеет тип Task<T>, то сам оператор await возвращает значение типа T − в этом случае, приведенное выше присваивание становится корректным относительно типов.

Но обратим теперь внимание на пару операторов из функции Sum

Task<int> sum = . . . ;
return await sum;

Здесь, по нашему предположению, оператор return, а следовательно, и функция Sum, должна возвращать значение типа int: смотрим на определение Sum и видим, что она возвращает значение типа Task<int> − приехали!

(Аналогичный разбор некорректностей в C# 5.0 можно найти здесь).

В чем причины обнаруженного явления и какова вытекающая из всего этого мораль?

1. Сами по себе конструкции async и await вполне обоснованы и являются частью асинхронной модели программирования, предложенной в языке Polyphonic C# и далее использованной и развитой в языке MC#.

   (Описание данной модели можно найти в одном из постов блога ISN).

2. Конструкция await не является универсальным средством синхронизации параллельных потоков, поскольку с ее помощью невозможно выразить некоторые более сложные схемы синхронизации, а потому разработчикам C# 5.0 и .NET пришлось оставить объекты типа Task со всеми сопутствующими им свойствами и методами.
   
3. Полные средства параллельности в любом языке программирования можно обеспечить либо
1. чисто языковыми средствами (например, async-методами, конструкциями channel , handler и связками, как в языке MC#), либо
2. с помощью библиотечных средств (например, Task Parallel Library в .NET 4.0)

однако, их необдуманное скрещивание, как проиллюстрировано выше, может приводить к некорректностям.

Главный разработчик средств C# 5.0 Mads Torgersen из Microsoft основополагающий документ “Asynchronous Programming in C# and Visual Basic” (октябрь 2010г.) начинает словами:

“ …a developer doesn’t need to grapple with conceptual overhead, architectural impedance mismatch and leaky abstractions”.

(“ … Разработчик не должен бороться с концептуальными перехлестами, архитектурными несовместимостями и плохо продуманными абстракциями”).

Удивительно, насколько в точности до наоборот, эти слова описывают то, что сделано в C# 5.0 …

Тем не менее, попытка введения именно языковых средств параллельности (упомянутых конструкций async и await) является прогрессивной тенденцией, поскольку такого рода средства позволяют писать компактные и понятные параллельные программы, имеющие строго определенную семантику. Еще один пример такого подхода − это язык Go (см. также пост) компании Google. А потому настоящее параллельное программирование только начинается − я так думаю!

Кроме процессоров NVIDIA, "Tianhe-1A" имеет 14336 6-ядерных процессоров Intel Xeon. Энергопотребление нового суперкомпьютера - 4 мегаватта ( у Jaguar'а - почти 7 Мвт). Разработчики отмечают, что если бы машина такой производительности была бы построена только на обычных процессорах, то её бы энергопотребление составило 12 Мвт.

Китайская машина спроектирована в Национальном Университете оборонных технологий (National University of Defense Technology), а установлена в Национальном суперкомпьютерном центре в Тяньжине (Tianjin). Также подчеркивается (а это важно ввиду всем известным играм с включением машин в Top500), что данный суперкомпьютер является уже "fully operational". Предполагается, что эта машина будет системой с "открытым доступом" для проведения широкомасштабных научных вычислений. В этой связи остается только пожалеть, что к отечественному суперкомпьютеру "Ломоносов" (0,35 петафлоп) в МГУ, вроде бы запущенному в ноябре 2009 г., до сих пор нет доступа.

Подробности реализации теста Linpack с использованием GPU можно найти в статье Massimiliano Fatica "Accelerating linpack with CUDA on heterogeneous clusters".

Одним из важных событий последних месяцев стало появление языка (параллельного) программирования Go от компании Google. Хотелось бы понять откуда он взялся, что принес нового, каковы перспективы его продвижения в многомиллионные массы практикующих программистов …

Во-первых, отметим, что данное новое средство параллельного программирования является языком, а не библиотекой с некоторым API. Т.е., здесь предлагается всего несколько конструкций (в контексте Go, это всего, фактически, две конструкции − goroutines и channels), которые делают язык полноценным средством параллельного программирования. Таким образом, когорта современных языков, таких как X10, Cilk++, MC# и некоторые другие, пополнилась новым членом.

Во-вторых, язык Go имеет теоретическую модель, восходящую к “взаимодействующим последовательным процессам” Хоара (CSP − Communicating Sequential Processes. Оттуда же, кстати, происходят и языки Occam и Erlang).

Интересна следующая цитата авторов этого языка, в которой они отвечают на вопрос “Why build concurrency on the ideas of CSP?”, и, в более общем плане, почему параллельное программирование может быть сделано более простым (см. также по этой теме пост “Параллельное программирование − это просто …”):

Concurrency and multi-threaded programming have a reputation for difficulty. We believe the problem is due partly to complex designs such as pthreads and partly to overemphasis on low-level details such as mutexes, condition variables, and even memory barriers. Higher-level interfaces enable much simpler code, even if there are still mutexes and such under the covers.

Как известно (см. пост “Join-модель параллельного программирования”), каждое средство для параллельного программирования должно предоставлять конструкции для

1. порождения параллельных процессов,
2. их взаимодействия между собой и
3. их синхронизации.

Посмотрим (естественно, совсем кратко) что предлагает нам в этом отношении язык Go.

Порождение параллельных процессов

Конструкция запуска параллельного процесса имеет стандартный вид − вызов запускаемой функции снабжается специальным ключевым словом, указывающим, что исполнение этой функции должно происходить одновременно с исполнением запускаемой функции. Ключевое слово async уже занято для этого в языках X10 и MC#, ключевое слово spawn используется в Cilk++, поэтому здесь было выбрано слово go:

go  list.Sort();

Функция, запущенная таким образом, называется “goroutine”. Goroutines являются легковесными (lightweight) сущностями, “укладываемыми” для исполнения в пул потоков.

Взаимодействие параллельных процессов

Ключевым понятием в Go, реализующим взаимодействие параллельных потоков, является понятие “канала” (channel). В связи с этим, интересна следующая цитата авторов языка, в которой, опять же, называются причины того, почему современное параллельное программирование является трудным, и предлагаются пути преодоления проблем:

Concurrent programming in many environments is made difficult by the subtleties required to implement correct access to shared variables. Go encourages a different approach in which shared values are passed around on channels and, in fact, never actively shared by separate threads of execution. Only one goroutine has access to the value at any given time.

Т.е., программирование на языке Go характеризуется слоганом:

Do not communicate by sharing memory; instead, share memory by communicating.

Здесь же заметим, что принцип “share memory by communicating”переносим и на случай распределенных вычислений − вычислений на кластере с теми же получаемыми преимуществами, которые отмечены в цитате.

Еще одна важнейшая вещь при использовании каналов для взаимодействия − это невозможность в принципе ситуации “data races”. В частности, отпадает необходимость использования для отладки тех частей, например, в Intel Parallel Inspector и PVS-Studio, которые ответственны за обнаружение такого рода ошибок. Таким образом,

A high-level approach, using channels to control access, makes it easier to write clear, correct programs.

Само понятие “канала” в параллельных языках имеет долгую историю. Оно изначально присутствует в математических исчислениях параллельных процессов, таких как CSP, CCS и π-исчисление, разработанных в 70-90-х годах прошлого века, а также в некоторых практических языках программирования того времени, например, в языке Occam.

В новой генерации средств параллельного программирования, это понятие является базовым в языке MC#, а также в библиотеке Joins).

В языке Go, каналы являются обычными объектами, создание которых выглядит, например, так:

c := make ( chan int, 100 );

В этом фрагменте, создается канал с, по которому будут передаваться целые числа, с емкостью внутренней очереди этого канала равной 100 сообщениям (целым числам).

Передача данных по каналу выглядит как

c <- 2;

а прием данных из канала оформляется как

int  x := <- c;

Отметим, что в языке Go по каналам могут передаваться только одиночные значения, тогда как в MC# по каналам могут посылаться произвольные n-ки значений.

Наконец, каналы в Go, как обычные объекты могут передаваться в качестве аргументов функций, в том числе, и goroutines, а также пересылаться по другим каналам (channels of channels). Типичная ситуация передачи канала в качестве аргумента goroutine − это использование этого канала для передачи сигнала о завершении работы параллельной функции:

	func  compute ( i, n int, c chan int )
	{
		for  ;  i < n; i++ {
		{
		   . . .
		}
		c <- 1; // signal that work is done
	}

Синхронизация параллельных процессов

Предыдущий пример уже был иллюстрацией использования каналов как средства синхронизации − одна функция ждет сообщения от другой функции, чтобы продолжить свою работу. И, действительно, каналы являются базовым средством синхронизации в языке Go (в дополнение к их основной функции передачи значений между процессами). А суть механизма синхронизации лежит в ограниченности внутренней очереди канала: если она полностью заполнена, то процесс, пытающийся послать очередное сообщение по данному каналу, заблокируется.

В частности, если канал имеет размер внутренней очереди равный 0 (так называемый “небуферизованный” или “синхронный” канал), то процесс, посылающий значение по каналу, заблокируется до момента выдачи некоторым другим процессом команды чтения из этого канала. Таким образом, как пишут авторы языка Go

Channels combine communication − the exchange of values − with synchronization …

В языке MC# каналы являются буферизованными с неограниченным размером буфера. Это позволяет решать часть задач синхронизации именно с помощью каналов, а решение остальных задач синхронизации обеспечивают связки (chords).

Отметим также важную дополнительную конструкцию синхронизации языка Go − конструкцию select:

	select {
		case   request := <- service:
			go run ( request );
		case    <- quit:
			return;
	}

Здесь, оператор select реализует ожидание прихода сообщения по одному из двух каналов − service или quit, выполняя, соответственно, либо обслуживание запроса, либо выход из обработки.

Заканчивая краткое описание параллельных средств языка Go, необходимо отметить, что авторы языка почему-то отказались от строгого проведения в жизнь ими же провозглашенного принципа отказа от низкоуровневых средств контроля доступа к разделяемым переменным.

В частности, в языке (точнее, в пакете sync, прилагаемом к языку) присутствует понятие “мьютекса”, а именно, 2 типа мьютексов: sync.Mutex и sync.RWMutex с довольно сложной семантикой их работы. Как, например, вам понравится , в частности, такое описание их работы:

For any call to l.RLock on a sync.RWMutex variable l, there is an n such that the l.RLock happens (returns) after the n'th call to l.Unlock and the matching l.RUnlock happens before the n+1'th call to l.Lock.

PS

Хочу поздравить всех с наступающим 11111011010 годом ! Новогоднюю открытку я не предусмотрел, но, по традиции, в качестве подарка хочу сделать ссылку на альбом электронной музыки “2010” от лэйбла Warp.

Join-модель параллельного программирования опирается на строгий математический базис − π-исчисление параллельных процессов, разработанное Р.Милнером, а точнее, на один из его вариантов, а именно, join-исчисление. Указанная математическая модель является универсальной в том смысле, что она может быть реализована в рамках различных парадигм программирования − как функциональной, так и императивной (объектно-ориентированной(ОО)). Примерами функциональных языков, основанных на join-модели, являются JoCaml и Funnel; примеры ОО-языков − Polyphonic C#, Cω, JoinJava, MC#.Ниже попытаюсь наглядно объяснить существенные, и они же оригинальные, черты данного подхода к параллельному программированию.

Каждый язык или иное средство (библиотека, набор “прагм” и т.д.) параллельного программирования должны иметь три обязательных компоненты, превращающих их в универсальный инструмент для такого программирования; а именно, средства для

1. порождения параллельных процессов,
2. взаимодействия этих процессов между собой и
3. их синхронизации.

В распространенных на данный момент ОО-языках, используются для этих целей низкоуровневые механизмы, такие как

1. потоки,
2. разделяемая память (переменные) и
3. различные блокирующие конструкции (locks, mutexes,мониторы, семафоры и т.п.).

Причем, в большинстве случаев, заметим это особо, эти механизмы доступны через API библиотек, имеющих большое количество разнообразных функций. Основная идея join-модели − это дополнить язык программирования минимальным, но достаточным набором параллельных конструкций, исключающих необходимость использования каких-либо библиотек указанного типа (в частности, вплоть до библиотеки System.Threading в .NET). В рамках ОО-парадигмы, это означает, что мы пытаемся расширить (последовательный) ОО-язык программирования естественными для него конструкциями, превращающими его в параллельный язык. Как это достигается в конкретных языках? Пройдемся по всем тем трем компонентам, которые были перечислены выше.

Порождение параллельных процессов

Одной из базовых конструкций в ОО-языке является функция/метод. В обычном последовательном языке методы являются синхронными − исполнение вызвавшей функции блокируется до тех пор, пока вызванный метод не завершит свою работу. Естественный способ сделать ОО-язык параллельным − это ввести в дополнение к синхронным двойственные им “асинхронные” методы, вызов которых завершается фактически мгновенно, а исполнение которых происходит одновременно с исполнением вызвавшего метода. Чтобы определить метод как асинхронный, пометим его специальным ключевым словом, например, async:

public async Compute ( int x, double y )
{
           .  .  .
}

(Заметим, что ключевое слово async стоит на месте типа возвращаемого значения, поскольку асинхронные методы в данной модели не возвращают значений). Отметим также, что мы превратили (пока частично) язык в параллельный, не привлекая таких дополнительных, и я бы их назвал “ортогональными” к ОО-подходу, понятий, как поток (thread), задача (task) и т.п., поскольку в данном подходе они оказываются ненужными. Асинхронные методы рассчитаны на “локальный параллелизм”, т.е., такие методы запускаются локально на одном из ядер многоядерной машины. В случае распределенной конфигурации − кластера или Grid-сети, эту идею можно обобщить: для возможного запуска метода на другой машине, достаточно пометить его в качестве “перемещаемого” (movable) метода, как это сделано в языке MC#. Использование только ключевого слова async для таких случаев недостаточно, поскольку для запуска метода на удаленной машине необходимо решать специфические проблемы, например, проблемы сериализации/десериализации передаваемых данных. Опять же, если конфигурация машины является специфической, например, гибридной с двумя типами процессорных ядер, как в случае процессора Cell, то для запуска метода на процессоре определенного типа (например, на SPE в Cell) его надо пометить соответствующим ключевым словом (в MC# методы, предназначенные для запуска на SPE-элементах Cell, помечаются модификатором spe). Заметим, что единая асинхронная модель программирования здесь сохраняется для всех типов параллельных архитектур, а потому, в случае использования, например, кластера с многоядерными узлами нет необходимости “скрещивать ежа с ужом” − OpenMP с MPI.

Взаимодействие параллельных процессов между собой

В обычных языках параллельного программирования взаимодействие процессов чаще всего происходит через общую память (разделяемые переменные), что требует привлечения блокирующих средств типа locks, mutexes и т.п. Кроме того, известно, что взаимодействие процессов по такому принципу − один из главных источников ошибок в параллельных программах. Для сохранения единой модели программирования как в локальном, так и в распределенном вариантах, а также для исключения использования низкоуровневых блокирующих средств, в join-модели программирования взаимодействие параллельных процессов происходит с использованием простого и интуитивного понятного понятия “канала”, в который можно данные посылать и из которого можно эти данные принимать. Например, канал по которому передаются тройки разнотипных чисел может быть объявлен следующим образом:

public channel c ( int x, float y, Complex z )
{
    .  .  .
}

Фактически получается, что “каналы” − это еще один вид методов, правда, оператор вызова которых несколько отличается от общепринятого по синтаксису

c ! ( 100, 0.1f, new Complex ( 2.0, -1.5 ) );

Принять данные из канала можно с помощью тех же средств, которые обеспечивают синхронизацию параллельных процессов в join-модели.

Средства синхронизации параллельных процессов

Средством синхронизации в join-модели являются так называемые “связки” (chords). Здесь, как и в случае синхронных и асинхронных методов, нам понадобится еще одно обобщение ОО-языка − будем считать, что метод, который обычно состоит из заголовка (сигнатуры) и вычислительного тела, теперь может иметь несколько заголовков. Соответственно, инструкции тела метода могут начать исполняться только тогда, когда произойдет вызов для всех заголовков этого метода − именно здесь оказывается скрытым механизм синхронизации join-модели. Заметим, что вызов нескольких заголовков принципиально возможен потому, что, в общем случае, вычисления происходят в многопоточной среде. Типичным примером связки (в языке MC#) является связка, состоящая из канала и обработчика, где последний предназначен для получения данных из ассоциированного с ним канала:

public class Buffer
{
  public handler Get string() & public channel Put ( string s )
  {
   return s;
  }
}

Принцип работы связки очевиден: если вызван обработчик, а данные в канал еще не поступили, то этот вызов будет заблокирован (до момента появления данных в канале). При поступлении данных в канал, когда обработчик еще не вызван, данные сохраняются во внутренней очереди канала. Легко понять, что низкоуровневые механизмы запирания и синхронизации здесь скрыты под более высокоуровневыми понятиями канала, обработчика и связки.

Ниже представлен пример связки, используемой для реализации барьерной синхронизации в известной программе вычисления чисел Фибоначчи:

public handler Get2 int() & channel c1 ( int x ) & channel c2 ( int y )
{
            return  x + y;
}

Здесь вызов обработчика Get2 будет заблокирован до тех пор, пока по каналам c1 и c2 не придут соответствующие значения, которые будут просуммированы в теле связки.

Важным свойством каналов и обработчиков, сближающих их с "делегатами" (delegates) языка C#, является то, что они могут передаваться в качестве аргументов другим методам, включая async- и movable-методы. В частности, можно посылать каналы и обработчики по каналам и принимать их с помощью обработчиков. Всё это вместе позволяет организовывать произвольные схемы взаимодействия между параллельными, распределенными процессами.

Резюме будет коротким: добавив полдесятка конструкций (ср. с количеством функций в OpenMP, Intel TBB, Microsoft PFX, MPI et al.), мы превратили обычный ОО-язык программирования в универсальный язык для параллельного программирования.

В качестве заключения, хочу предложить, по традиции, две задачи:

1. Каналы и обработчики не являются обычными объектами; в частности, для них не предусмотрены конструкторы и они не могут участвовать в операциях присваивания. Однако, в некоторых задачах возникает ситуация, когда главная программа получает от процесса-потомка канал, который ей необходимо как-то сохранить, чтобы в дальнейшем иметь возможность многократно посылать данные по нему процессу-потомку.

Тем не менее, данную ситуацию легко смоделировать с помощью некоторой связки, обеспечивающей прием канала от процесса-потомка и дальнейшее многократное использование этого канала для передачи значений. Как может выглядеть эта связка?

2. Какой из современных языков программирования, не упомянутый выше, также использует концепцию каналов для взаимодействия параллельных процессов между собой и допускает, в частности, передачу каналов по каналам?

PS

На сайте Интернет-университета информационных технологий недавно опубликован учебный курс “Параллельное программирование для многоядерных процессоров”, в котором рассматриваются Microsoft PFX и MC#.

Параллельный вариант решения этой задачи можно получить элементарным образом: если мы зафиксируем первого ферзя в самом верхнем ряду, в первой клетке слева, то нахождение всех расстановок остальных ферзей можно поручить одному процессору. Аналогично, если зафиксировать первого ферзя в этом же ряду во второй клетке слева, то отыскание всех возможных расстановок оставшихся ферзей можно поручить другому процессору. Ну и т.д.

В общем случае, для подходящего числа M ( M < N, где N − размер доски) можно найти все допустимые расстановки ферзей в первых M рядах, применив всё ту же функцию Backtrack на основе битовых векторов (см. код, приведенный в первой части). Множество таких расстановок можно считать совокупностью (очередью) заданий для решателей, каждый из которых запускается на отдельном процессоре. Подсчет количества вариантов расстановок оставшихся N-M ферзей решатели производят, снова пользуясь базовой функцией Backtrack. Полный код программы на языке MC#, реализующий такой подход, и предназначенный для исполнения на многоядерной машине, приведен ниже.

using System;

public class Task   {

 public int left, down, right;

 public Task ( int l, int d, int r ) {

  left  = l;
  down  = d;
  right = r;

 }

}

//**************************************************//

public class NQueens   {

 public static long totalCount = 0;

 public static void Main ( String[] args ) {

  int   N = System.Convert.ToInt32 ( args [ 0 ] );   //  Board size
  int   M = System.Convert.ToInt32 ( args [ 1 ] );   //  Number of fixed queens
  int   P = System.Convert.ToInt32 ( args [ 2 ] );   //  Number of workers

  NQueens nqueens = new NQueens();

  nqueens.launchWorkers ( N, M, P, nqueens.getTask, nqueens.sendStop, nqueens );

  nqueens.generateTasks ( N, M, P, nqueens.sendTask );

  for ( int i = 0; i < P; i++ )
   nqueens.getStop ? ();

  Console.Write     ( "Task challenge : " + N + "   " );
  Console.WriteLine ( "Solutions = " + totalCount );

 }

 //******************************************************************************//

 public handler getTask Task(int count ) & channel sendTask ( Task task ) {

  totalCount += count;
  return ( task );

 }

 //******************************************************************************//

 public handler getStop void() & channel sendStop () {
  return;
 }

 //******************************************************************************//

 public async launchWorkers ( int N, int M, int P, handler Task(int) getTask,
                              channel () sendStop, NQueens nqueens            ) {

  for ( int i = 0; i < P; i++ )
   nqueens.Worker ( i, N, M, getTask, sendStop );

 }

 //******************************************************************************//

 public void generateTasks ( int N, int M, int P, channel (Task) sendTask ) {

  int   y     = 0;
  int   left  = 0;
  int   down  = 0;
  int   right = 0;

  int   MASK  = ( 1 << N ) - 1;

  MainBacktrack ( y, left, down, right, MASK, M, sendTask );

  Task finish_marker = new Task ( -1, -1, -1 );

  for ( int i = 0; i < P; i++ )
   sendTask ! ( finish_marker );

 }

 //********************************************************************************//

 public void MainBacktrack ( int y, int left, int down, int right, int MASK,
                             int M, channel (Task) sendTask                  ) {

  int   bitmap, bit;

  if ( y == M )
   sendTask ! ( new Task ( left, down, right ) );
  else   {

   bitmap = MASK & ~ ( left | down | right );

   while ( bitmap != 0 )   {

    bit   = -bitmap & bitmap;
    bitmap = bitmap ^ bit;

    MainBacktrack ( y + 1, ( left | bit ) << 1, down | bit, ( right | bit ) >> 1,

                    MASK, M, sendTask                                            );

   }

  }

 }

 //********************************************************************************//

 public async Worker ( int myNumber, int N, int M, handler Task(int) getTask,

                  channel () sendStop                                    ) {

  int    MASK  = ( 1 << N ) - 1;

  int    count = 0;

  Task   task  = (Task) getTask ? ( count );

  while ( task.left != -1 )   {

   WorkerBacktrack ( M, task.left, task.down, task.right, MASK, N, ref count );

   task  = (Task) getTask ? ( count );
   count = 0;

  }

  sendStop ! ();

 }

 //********************************************************************************//

 public void WorkerBacktrack ( int y, int left, int down, int right, int MASK,

                               int N, ref int count                           ) {

  int   bitmap, bit;

  if ( y == N )
   count++;
  else   {

   bitmap = MASK & ~ ( left | down | right );

   while ( bitmap != 0 )   {

    bit   = -bitmap & bitmap;
    bitmap = bitmap ^ bit;

    WorkerBacktrack ( y + 1, ( left | bit ) << 1, down | bit, ( right | bit ) >> 1,
                    MASK, N, ref count                                             );

   }

  }

 }

}

Специфическая особенность языка MC# заключается в том, что для того, чтобы получить из данной программы распределенный вариант для исполнения на кластере, достаточно заменить пометку параллельной функции Worker c async на movable. Также, данный код программы без изменений работает как под Windows, так и под Linux.

А причем здесь какие-то странные числа, вынесенные в заголовок, можете спросить вы? Ну, про 9,58 многие уже догадались … А вот ко второму числу подойдем чуть издалека …

Относительно задачи N-Queens можно задаться вопросом − для доски какого максимального размера мы можем её решить, т.е., подсчитать количество всех возможных расстановок? Оказывается, этот размер не так уж и велик. Впервые, решение для N = 24 было получено в 2004 г. (точнее, 11 апреля 2004 г.). Количество решений составило

227 514 171 973 736

(см. отчет “Solving the 24-queens problem using MPI on a PC Cluster”). Решение для N = 25 не заставило себя долго ждать − оно было получено 11 июня 2005 г. и составило

2 207 893 435 808 352

Для получения решения было использовано 260 машин и счет продолжался более 6 месяцев (см. http://proactive.inria.fr/index.php?page=nqueens25). Трудоемкость этой задачи оценивается в более, чем 50 лет работы одного компьютера.

С тех пор, данная задача несколько раз использовалась в соревнованиях по Grid-вычислениям (см., например, http://www.etsi.org/plugtests/grid/IVGRID_PLUGTESTS.htm), а результат для N = 25 оставался до недавнего времени рекордом.

С середины прошлого года для нас стали доступны мощные кластеры, появившиеся в России – “CКИФ-МГУ” (5000 ядер, МГУ) и МВС-100К (7920 ядер, Межведомственный суперкомпьютерный центр РАН). Возникло естественное желание попытаться решить эту задачу для N = 26. Дополнительным стимулом к этому стала попытка решить эту задачу в проекте NQueens @Home (http://nqueens.ing.udec.cl/) на основе системы распределенных вычислений BOINC, с помощью которой можно объединить для решения обычные PC с установленными на них специальными клиентскими программами. Данный проект стартовал в августе 2008 г.

Вначале мы просто проверили работоспособность системы MC# на большом количестве процессоров − результаты обнадежили. Вот протокол решения задачи для N = 21 на кластере “СКИФ-МГУ” на 4200 ядрах:

В качестве базового алгоритма был взят алгоритм на основе битовых векторов, но использующий симметрии (см. http://www.ic-net.or.jp/home/takaken/e/queen/index.html). Оказалось, что этот алгоритм возможно распараллелить в соответствии с подходом, упомянутым выше. Более того, для N = 26 задача на самом верхнем уровне удачно разбивается на 277 независимых частей, каждую из которых можно считать в виде отдельного задания на кластере. И 18 ноября 2008 г. счет начался … Он проходил обычной ручной постановкой очередного задания на тот или кластер. Трудоемкость нескольких особо сложных заданий превысила 30 000 процессоро-часов.

Просчет заданий шел не так быстро как хотелось бы, поскольку оба кластера всегда перегружены работой − иногда в очередях стоит 100−200 заданий. Но, тем не менее, проект NQueens@Home нам удалось догнать очень быстро − на сегодняшний день он вышел лишь за 50% выполнения всей задачи.

Однако, в этом деле нашелся свой Усэйн Болт . Когда, в конце июля этого года мы начали приближаться к завершению нашего счета, то обнаружили в Интернете ссылку вот на этот вот сайт − http://queens.inf.tu-dresden.de/?l=en&n=0. Оказалось, что в рамках проекта Queens@TUD 11 июля 2009 г. было получено решение для N = 26:

22 317 699 616 364 044

Но получено оно было на основе принципиально иной технологии. Немецкие специалисты воспользовались для решения задачи технологией на основе FPGA, что по-русски звучит как ПЛИС (программируемые логические интегральные схемы). Т.е., другими словами, они построили специализированную многопроцессорную вычислительную машину, которая предназначена для решения одной единственной задачи – задачи N-Queens. Правда, и счет у них начался раньше, чем у нас − 14 октября 2008 г. Схема их решателя и была приведена на картинке в 1-ой части этого поста.

Ну а что мы? Наш счет закончился 30 августа 2009 г., и мы лишь порадовались тому, что результат полностью совпал с полученным немецкими компьютерщиками; т.е., и сам результат верифицировали, и удостоверились что наша программа была корректной. Код программы, результаты и полные протоколы запусков скоро будут выставлены на нашем сайте www.mcsharp.net.

Какие выводы можно сделать из этой истории? Наверно, один из них состоит в том, что системы на базе FPGA будут вне конкуренции для получения рекордных результатов в решении отдельно взятых задач. С другой стороны, появились упоминания о попытках решения этой задачи на GPU. C третьей стороны, наличие кластеров хотя бы с 20 000 ядрами позволит и с помощью этих универсальных средств посоревноваться в решении специальных счетных задач.

Другие выводы и свои мысли по этому поводу можно оставлять в комментариях. Интересно, сможет ли кто-нибудь правильно спрогнозировать когда будет получено решение этой задачи для N = 27 ?

Наверняка, всем хорошо известна задача о расстановке ферзей на шахматной доске таким образом, чтобы они взаимно не били друг друга. Суть задачи, а точнее, ее обобщения состоит в том, чтобы подсчитать количество всех возможных таких расстановок на доске размером N x N (NQueens Problem). Удивительно то, что хотя самой задаче уже около 150 лет, но существенный прорыв в ее решении произошел совсем недавно, в 2002 г. (а еще один прорыв состоялся в июле 2009г., но об этом позже).

(Прежде чем читать дальше, тем, кто никогда не пробовал самостоятельно запрограммировать решение этой задачи, настоятельно рекомендуется попытаться сделать собственную реализацию.)

И автором этого прорыва, как вы уже, наверно, догадались, стал человек из Китая по имени Qiu Zongyan из Пекинского университета (его статья помещена в журнале ACM SIGPLAN Notices).

Поскольку алгоритм решения задачи представляет собой, в сущности, полный перебор, то, чтобы сделать его максимально быстрым, нужно эффективным образом организовать структуры данных, отображающие текущую конфигурацию ферзей на доске с тем, чтобы потратить минимальное число операций на переход к следующей конфигурации.

Суть гениального по своей простоте приема, предложенного Qiu Zongyan, проиллюстрируем на примере.

Предположим, что в алгоритме ферзи выставляются на доску по порядку, начиная с самой верхней горизонтали. Например, после расстановки двух первых ферзей мы можем иметь следующую конфигурацию на двух первых горизонталях доски 8 x 8:

Теперь, чтобы вычислить допустимые позиции на третьей горизонтали, нам нужно определить какие из позиций на этой горизонтали находятся под боем ранее выставленных ферзей; а именно, какие позиции принадлежат

1) диагоналям, по которым выставленные ферзи бьют справа-налево,

2) вертикалям, по которым ферзи бьют сверху-вниз,

3) диагоналям, по которым ферзи бьют слева-направо.

Представим эти позиции, находящиеся под боем (отметив их единичками) в виде соответствующих трех битовых векторов:

Поэлементно складываем все эти вектора логически по ИЛИ и получаем занятые/свободные позиции на третьей горизонтали:

Итак, у нас имеется 3 возможных способа поставить очередного ферзя. Выбираем, например, вторую позицию слева и ставим туда третьего ферзя.

А теперь – внимание ! – ключевой момент алгоритма. Как нам получить новую конфигурацию доски, а именно, занятые позиции теперь уже на четвертой горизонтали? А делаем всего лишь вот что − ставим единицу во вторую позицию (т.е., позицию, куда мы поставили нового ферзя) каждого из векторов left, down и right, и

a) сдвигаем вектор left влево на 1 бит (вычисляем позиции под боем на диагоналях, идущих от уже поставленных ферзей справа-налево),

б) ничего не делаем с down,

в) сдвигаем вектор right вправо на 1 бит (аналогично пункту а, но для диагоналей слева-направо).

Суммируем чего мы добились − мы представили конфигурации ферзей на доске в виде битовых векторов, а их модификацию выразили исключительно через битовые операции.

Остальная часть алгоритма − это обычный бектрекинг с целью получения всех возможных расстановок. Полное решение этой задачи на языке C# представлено ниже.

using System;
public class NQueens   {
 public static int Backtrack(int y, int left, int down,
 int right, int N, int MASK)
 {
     int  bitmap, bit;
     int  count = 0;
     if (y == N) {
         return ( 1 );
     } else {
         bitmap = MASK & ~(left | down | right);
         while (bitmap != 0) {
             bit = -bitmap & bitmap;
             bitmap ^= bit;
             count += Backtrack(y+1,(left | bit)<<1, down | bit,
             (right | bit)>>1, N, MASK);
         }
         return ( count );
     }
 }
 public static void Main(String[] args )
 {
     int N    = Convert.ToInt32 ( args [ 0 ] );
     int MASK = (1 << N) - 1;
     int result = Backtrack(0, 0, 0, 0, N, MASK);
     Console.WriteLine ("N=" + N + " -> " + result);
 }
}

Схема параллелизации этого алгоритма не так интересна − она очевидна, и, похоже, единственна. О ней и о сопутствующих результатах, я надеюсь, мы поговорим в планирующемся продолжении этого поста. А пока лишь упомяну, что детальное описание приведенного выше алгоритма вместе со схемой параллелизации на языке MC# можно будет вскоре найти в учебном курсе “Параллельное программирование для многоядерных процессоров”, который будет размещен на сайте Интернет-университета информационных технологий и на сайте Microsoft MSDN Academic Alliance . Варианты решения этой же задачи с использованием OpenMP и Intel TBB можно найти в документе “Parallelizing N-Queens with the Intel Parallel Composer” , а с использованием Cilk++ - здесь.

В заключении, по традиции две загадки − как вы думаете, что это такое?

1)

  int t(int a, int b, int c){
     int d=0, e=a&~b&~c, f=1;
     if (a)
       for (f=0; d=(e-=d)&-e;)
         f+=t(a-d,(b+d)*2,(c+d)/2);
     return f;
  }
  int main( int argc, char *argv[]) {
    int q = atoi ( argv [ 1 ] );
    printf("%d\n",t(~(~0<<q),0,0));
  }
  

2)

Ответы − в следующем посте.

Более точно, на вышеупомянутой конференции был представлен доклад Claudio Russo из Microsoft Research (Cambridge, United Kingdom) под названием “Join patterns for Visual Basic”. Базовые идеи этого доклада представляет следующий абзац:

"Concurrent Basic extends Visual Basic with stylish asynchronous concurrency constructs derived from the join calculus. Our design advances earlier Microsoft Research work on Polyphonic C#, Comega and the Joins Library.” 

В данном абзаце перечислены некоторые названия, которые, скорее всего, мало знакомы или совсем незнакомы практикующим программистам (хотя некоторые из них уже были отмечены в одном из моих предыдущих постов, см. здесь ). 

История же эта началась с FOOL 9 :-) - 9-ой международной конференции “Foundations of Object-Oriented Languages” (январь 2002г.), на которой, опять же, люди из Microsoft Research, а именно, Nick Benton, Luca Cardelli, Сedric Fournet предложили новую модель асинхронного (читай, параллельного) программирования, базирующуюся на определенной формальной математической модели – join-исчислении. 

Языки программирования, на самом деле, являются довольно консервативной областью – всё здесь, или, почти всё, уже изобретено, а потому появление новой замечательной модели есть вещь неординарная. Сам математический формализм – join-исчисление – по своей сути, не ориентирован на какой-либо конкретный язык программирования, а потому применим как к функциональным, так и к императивным/объектно-ориентированным языкам. Результатами такого применения среди функциональных языков являются языки Jocaml  и Funnel, а соответствующими расширениями объектно-ориентированных языков Java и C# стали Join Java и Polyphonic C#. Последний из названных языков стал впоследствии частью языка Сomega, другая часть которого известна сегодня как LINQ. 

Новая предложенная модель хоть и отличается от концепций параллелизма, имевшихся до сих пор, на самом деле, не так уж и сложна. Тем не менее, компания Microsoft из языка Comega внедрила поначалу в практику только LINQ, а в качестве средства параллельного программирования предложила еще одну реинкарнацию концепции потоков – библиотеку Task Parallel Library (TPL). Возможно, что в этом случае Microsoft посчитала, что программистское сообщество не готово к переходу на концептуально новый параллельный язык программирования, предложив ему еще одну библиотеку. 

Однако, появление Concurrent Basic свидетельствует о том, что Microsoft, возможно, всё-таки начала внедрять эту модель, зайдя со стороны Basic’а – воспримет ли новые идеи, для начала, Basic-сообщество? 

О самих ключевых идеях Concurrent Basic’а планирую рассказать в ближайших моих постах. В частности, на CB имеется реализация известной игры Конвэя “Жизнь”, которая являлась одним из заданий конкурса Intel Threading Challenge 2008. Решение всех заданий этого конкурса на языке MC#, который также принадлежит к группе языков, базирующихся на join-исчислении, включены в дистрибутив новой версии MC# 2.1.

В заголовок этого поста вынесено начало эпиграфа к книге K.Mani Chandy, Jayadev Misra “Parallel Program Design: A Foundation”. Полностью этот эпиграф выглядит так:

“The most general definition of beauty … Multeity in Unity”

(Samuel Taylor Coleridge, “On the Principles of Genial Criticism”, 1814).

К чему это?

Хотелось бы еще на одном примере показать, как грамотно выбранная система обозначений (читай, язык программирования) позволяет очень просто сформулировать алгоритм решения задачи, который в другой бы нотации записывался очень сложно, или, вообще бы казался нереализуемым.

Начнем чуть издалека. Многим хорошо известен язык логического программирования Prolog, программирование на котором в чистом виде состоит в том, что мы, в основном, выписываем правила того, ЧТО должно быть сделано для решения задачи, оставляя вопрос КАК это делать интерпретатору этого языка. Т.е., интерпретатор языка Prolog выполняет любую программу единым образом – пытается сделать истинными предложения, из которых составлена программа, используя, возможно, откаты назад (так называемый бектрекинг). 

Существует довольно широкий класс задач, которые также можно решать некоторым единым способом. Это класс задач для которых решение находится с помощью итерационного процесса, который останавливается когда система перешла в некоторое стабильное состояние, или достигла, как говорят, некоторой неподвижной точки. 

В упомянутой выше книге, излагается формализм для представления (программирования) такого рода задач – введена программная нотация и разработаны теоретические методы рассуждений (логика) о программах, записанных в данной нотации. Весь этот подход получил название Unity. Следует заметить, что указанная книга и сопутствующие статьи составляют один из краеугольных камней науки о параллельном программировании, наряду с работами Хоара, Дейкстры и Милнера. 

Язык программирования Unity понять очень легко – мы его продемонстрируем на примере записи программы нахождения наибольшего общего делителя двух целых чисел: 

Program gcd

            declare x, y : integer

            initially x, y = X, Y

            assign

                        x, y := x – y, y  if x > y

                      | x, y := x, y – x  if y > x

end { gcd } 

Выполняется программа такого вида следующим образом: выбирается  и вычисляется одно из присваиваний, для которого истинно условие выполнения. Если таких присваиваний несколько, то (недетерминированно) выбирается для исполнения только одно из них. Если таких присваиваний нет, то программа останавливается. Такого рода итерации продолжаются до тех пор, пока не наступит стабильное состояние – значения переменных на очередной итерации совпадут с предыдущими их значениями. (Более практические вопросы – ввод/вывод, модуляризация, и т.д. здесь, в иллюстративных целях, опущены). Заметим также, что данная нотация является внутренне параллельной –  вычисление выражений, разделенных запятыми, в правой части присваиваний может выполняться одновременно. В частности, в указанной выше книге имеется несколько разделов, посвященных реализации этой модели вычислений на различных параллельных архитектурах – системах с передачей сообщений, систолических массивах, и т.п. 

Теперь реализуем с помощью Unity модель некоторой системы, которая обсуждалась в комментариях к моим двум предыдущим постам. А именно, требуется реализовать в виде двух параллельных процессов модели логических элементов И-НЕ, связанных между собой перекрестными связями. А именно, выход y1 первого элемента вычисляется как

y1 =  NOT  ( x1  AND y2 ),

а выход y2 второго элемента вычисляется как

y2 = NOT ( x2 AND y1 ).

Как работает данная система – было проанализировано “на бумажке” в комментариях к предыдущим постам. Чтобы получить аналогичное поведение, мы просто напросто переносим определение системы в формализм Unity: 

Program Model

            declare x1, x2, y1, y2 : integer

            initially x1, x2, y1, y2 = 0, 0, 0, 0

            assign

                        y1, y2 = 1- ( x1 & y2 ), 1 - ( x2 & y1 )                     

end { Model } 

Программа (причем, параллельная) получена!

И как вам это? 

PS

Всех с наступающим Новым годом !

И в качестве альбома для прослушивания на Новый год рекомендую

один из лучших дисков 2007 года – Burial “Untrue”

Вы уже имеете 2-х ядерную машину? Наверняка, это так. И насколько оба ядра оказываются загруженными при запуске типичных приложений? А, может быть, у вас есть доступ к 4-х ядерной машине или даже к 8-ми ядерной? А как насчет попользоваться, а лучше, загрузить по полной процессор Larrabee ? (Кто вдруг не знает, что это такое, может посмотреть некоторое обсуждение здесь.) А вы задумывались по-настоящему о том, как такие машины программировать, чтобы, с одной стороны, действительно получить прирост производительности, соответствующий имеющимся ресурсам (т.е., количеству ядер), а с другой стороны, не снизить, как сейчас говорят, продуктивность в программировании, т.е., возможность писать  примерно такое же количество отлаженных строк кода за единицу времени, что и раньше ?

Замечу, что под термином “высокоуровневое программирование” я понимаю не программирование на языке C++ (в отличие, допустим, от “низкоуровневого” программирования на языке С), а программирование, главным образом, на байт-кодовых языках (managed languages), а среди них, в первую очередь, на языке C#. Причем я не буду сильно бороться против тезиса, что байт-кодовые языки непригодны или, даже более того, несовместимы с HPC (high-performance computations). В этом отношении, мой взгляд двоякий: во-первых, мы имеем в качестве данной такую ситуацию – имеются многоядерные машины (которые теперь уже, повторюсь, есть практически у всех ), и необходимо (опять же, уже каждому разработчику, если он хочет, чтобы его приложение выполнялось эффективно и конкурировало с аналогичными разработками) писать для них параллельные программы. Не забудем также тот аспект, что и программированию студентов нужно учить теперь тоже параллельному, причем, как можно раньше, на 1-2-х курсах.

Во-вторых, шансы побороться с утверждением, что managed-языки неприменимы для HPC, все-таки есть. Конечно, чтобы выжать максимальную производительность из приложения часто даже применения языка С недостаточно, и в этом случае переходят на ассемблерные вставки в код. (Показательным примером здесь является, скажем, программа перемножения матриц, ориентированная на процессор Cell Broadband Engine, с которой можно ознакомиться здесь.) С другой стороны, взгляните на такие оценки, очень близкие к реальным: 2-х дневный прогноз погоды по Европейской части России считается на кластере с достаточным количеством процессоров 1,5 – 2 мин., где само приложение написано на C + MPI + OpenMP (аналогичные результаты по времени получаются и для связки Fortran + MPI + OpenMP). Допустим, что мы это приложение переписали (или написали заново) на языке C# с соответствующими средствами параллелизации. Если предположить, что в последнем случае производительность приложения будет в 1,5 – 2,5 раза ниже по сравнению с первым вариантом, то, тем не менее, мы тот же 2-х дневный прогноз погоды сможем получать на тех же вычислительных ресурсах за 3 – 5 мин.

С другой стороны, существуют объективные данные, что продуктивность работы программистов на высокоуровневых языках при разработке промышленных (в том числе, параллельных и распределенных) приложений в 2-10 раз выше, чем при использовании языков уровня C++. В применении к нашему примеру, это будет означать, что если на разработку параллельного варианта прогнозного приложения на языке C (или Fortran) понадобится 6 месяцев, то на C# такой вариант будет разработан, отлажен и запущен в промышленную эксплуатацию приблизительно за 1 месяц. Понятно, что здесь кроется довольно существенная экономия реальных денег. Не забудем также про то, что такого рода приложения постоянно модифицируются и дорабатываются – понятно, что на высокоуровневых языках такая процедура будет проходить значительно быстрее, качественнее, а значит, в конечном итоге, и дешевле.

Вообщем, цель этого блога – освещение возможностей высокоуровневого параллельного программирования для современных компьютеров, и мой сегодняшний пост является введением в эту проблематику с кратким перечислением всего того, что будет в нем рассмотрено в дальнейшем. 

Язык C#, фактически, неотделим от платформы .NET, и в ближайших постах мы с нее  и начнем рассмотрение вопросов программирования на параллельных managed-языках. Здесь только отмечу, что платформа .NET Framework, изначально являвшаяся разработкой фирмы Microsoft, еще шире пошла в программистские массы с появлением системы Mono (www.mono-project.com ) – свободной реализации .NET для Unix-подобных систем. В этом направлении дело дошло до того, что Mono (.NET) уже работает на игровых приставках PlayStation 3 и даже на iPhone! Сам язык C# также бурно развивается. Еще недавно мы обсуждали и продолжаем осваивать средства C# 2.0, а теперь средствами регулярного программирования становятся C# 3.0 и на подходе его следующая версия C# 4.0.

Язык C# со всевозможными расширениями на основе библиотек типа Parallel FX – это, можно сказать, инженерный подход к решению проблемы параллелизма. Существует, естественно, и научный подход к этой проблеме, суть которого состоит в разработке нового языка для параллельного программирования – недаром по научным конференциям соответствующей тематики кочует слоган “It’s time for a new language”. И тотальный переход в “параллельный мир” к этому действительно побуждает. Ученые, в свою очередь, не остаются в долгу – упомянем, например, UPC, Polyhonic C#, MC#, X10, Cilk++, Chapel, Ct и др. Хотя область языков программирования, по моему мнению, является довольно консервативной -  новые, по настоящему ценные,  модели программирования и соответствующие языковые средства появляются довольно редко, но в этих языках постепенно прорезываются новые интересные конструкции, которые станут базовыми средствами параллельных языков будущего. Все эти языки и некоторые другие будут обозреваться в наших постах, а то как эти языки соревнуются между собой в области HPC, можно найти на сайте www.hpcchallenge.org.

Еще одной темой наших обсуждений, когда мы говорим о программировании многоядерных процессоров, конечно же, станет библиотека Parallel FX от Microsoft, состоящая из Task Parallel Library (TPL) и Parallel LINQ (PLINQ). У Microsoft есть превосходный ресурс по этой тематике - http://msdn.microsoft.com/en-us/concurrency/default.aspx, который содержит множество отличного материала, к которому мы будем часто обращаться и который будем обсуждать в этом блоге. Вообще, фирма Microsoft (заметим, совместно с Intel) развила бурную деятельность в области параллельных вычислений, охватывающую весь спектр компьютеров – от многоядерных машин до мощнейших суперкомпьютеров (кстати, поинтересуйтесь на каком месте в Top500 – рейтинге пятисот самых мощных суперкомпьютеров в мире, находится машина, использующая новейший продукт от Microsoft – Windows HPC Server 2008, и где эта машина конкретно установлена, и вы сильно удивитесь).    

В заключение, две загадки из довольно разных областей:  

1)      язык Ct основан на языке C, т.е., не является байт-ориентированным; тем не менее, для него существует JIT-компилятор; для чего он нужен и чем занимается этот компилятор ?

2)      НПО “Сатурн” (г. Рыбинск) в сентябре 2008 г. запустило суперкомпьютер “AЛ-100”; в ноябре это НПО обанкротилось и было национализировано (см. “Коммерсант”, 3 декабря 2008 г. ); что бы это значило ?

Свои ответы, а также любые предложения, замечания и комментарии оставляйте здесь. По-моему, у нас будет достаточно тем, которые надо обсудить …                         

Ю.Сердюк  ( info ( at ) mcsharp.net, www.mcsharp.net ).

  Меня зовут Сердюк Юрий. Работаю в Институте программных систем Российской академии наук (ИПС РАН) в г. Переславле-Залесском. Занимаюсь параллельными вычислениями; конкретно, областью научных интересов являются языки для параллельного программирования и их формальные (математические) основы. С недавних пор (кстати, еще до начала многоядерной революции) появились идеи и желание сделать что-то практическое, т.е., то, чем реальным разработчикам захотелось бы пользоваться ежедневно в своей работе. Часть материалов нашего проекта MC# представлена здесь.

С удовольствием принял приглашение от Intel освещать тему высокопроизводительных (читай, многоядерных, многопоточных и т.п.) вычислений на языках высокого уровня (managed languages) в рамках российской части Intel Software Network. С одной стороны, хочется поделиться собственными мыслями – а соответствующих тем имеется великое множество, а с другой стороны, интересно узнать что думает на эту тему программистское сообщество, и насколько внутри него есть потребность в упомянутых инструментах. Наконец, хотелось бы просто привлечь к этой тематике побольше народу, поскольку она является, по моему мнению, достаточно перспективной. 

Мне кажется, что сейчас в программировании наступает период, аналогичный тому, что был 50 лет назад, когда произошел переход от программирования на машинных (ассемблерных) языках к языкам программирования высокого уровня (Алгол, Фортран). Конечно, мы при этом несколько потеряли в эффективности исполнения программ, что стало платой за удобства программирования, но последнее, как мы сейчас видим, очевидно перевесило первое.  

Сейчас базовыми средствами параллельного программирования являются C/C++, MPI и OpenMP, которые относятся к низкоуровневым средствам, и программировать на которых трудно. Переход к более абстрактным, высокоуровневым инструментам не будет таким простым и безболезненным по целому ряду причин: одна из них – наличие огромного объема уже наработанного программного обеспечения. Появится ли реально что-то новое, более высокоуровневое и достаточно эффективное – см. об этом в следующих постах данного блога. 

Комментарии можно оставлять здесь или отправлять непосредственно мне на info (at) mcsharp.net.