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

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

Можно говорить о том, что наш наши КБ и НИИ безинициативны и не делают использовать доступные вычислительные мощности. Но вот вам обратный пример: Институт объединенных ядерных исследований при выполнении зарубежных заказов по проектированию циклотронов был вынужден использовать обычный персональный компьютер, неизвестно, чем бы завершились проекты, но ребятам удалось использовать видеоадаптер для значительного ускорения вычислений в рамках проекта "CBDA: Cyclotron Beam Dynamics Analysis". С другой стороны университетские кластеры просто простаивают. К примеру, кластер МГТУ им. Баумана загружен всего на несколько процентов, по словам инсайдеров.

В России есть отдельные проекты, которые пытаются решить эту задачу, например, CAEBeans под руководством проф. Л.Б. Соколинского, ЮУрГУ. Другой пример: проект MathCloud Алексея Тарасова из ИСА РАН.

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

Данный подход называют “Распараллеливание черного ящика”. Он состоит из 4х основных шагов:

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

Для каждого этапа я использовал один из компонентов инструментария Intel® Parallel Studio: Parallel Amplifier – Hotspots, Parallel Composer, Parallel Inspector и Parallel Amplifier – Concurrency и Lock and Waits, соответственно. Первому шагу я уже посвятил один из своих блогов: http://software.intel.com/ru-ru/blogs/2009/10/26/2002338/. Я планирую опубликовать блоги по оставшимся этапам. Так что у вас будет возможность задать вопросы, которые вы не задали на семинаре.

Теперь о моих впечатлениях: Не хочу обидеть Нижегородцев, но я очень рад тому, что география аудитории онлайн-семинара оказалась довольно обширной: начиная дальним востоком России и заканчивая средней Европой. Попытаюсь объяснить почему. В силу своего географического расположения, студенты Нижнего Новгорода имеют возможность как минимум 1 раз в квартал посещать технические семинары, которые проводят инженеры компании Intel «в живую». У студентов других городов такой возможности, к сожалению, нет. Мне самому повезло, так как во время учебы я принимал участие (приезжал из Уфы) в Зимней школе 2005 и в Летней школе 2007 от компании Интел, которые проходили в Нижнем Новгороде. Таким образом, к окончанию учебы я уже знал, какие знания и какой опыт от меня будит требовать работодатель.

Вести онлайн семинар оказалось гораздо труднее, чем в живую. Во-первых, во время семинара я не мог понять, насколько интересно и понятно содержание презентации и демонстраций, т.к. нет ран-тайм общения с аудиторией. К примеру, когда я вижу, что большая часть засыпает или нет вообще никаких вопросов со стороны слушателей, то я стараюсь повернуть русло в другую сторону и попытаться заинтересовать аудиторию. Если это не в 8-9 утра, конечно :). Во-вторых, это задержка видео и звукового сигнала. Когда логически переходишь к новому слайду или картинке, но аудитория еще не видит ее, это порой сбивает с мысли. Этот список можно продолжать. Но, как говорится, ”Первый блин комом”. Мы постараемся учесть все ошибки, и следующий “вебинарь” получится лучше с технической точки зрения. Предлагаю обсудить ваши впечатления. Пользуясь случаем, хочу задать вопрос: какие онлайн семинары вы бы хотели посетить?. Стоит заметить, что я уже получил запросы на подробное описание Advanced Vector Extension (AVX) и Intel® Parallel Debugger Extension (PDE).

Я думаю, что мы найдем специалистов, которые поделятся с вами своими знаниями и опытом. Надеюсь на то, что встречаться с вами на онлайн семинарах станет хорошей традицией.

Спасибо Вам, Спасибо Диме и Маше!

Add-on от Дмитрия:

Да пожалуйста! :). Пользуясь правами администратора ISN, я беспардонно влезу в эту запись чтобы еще раз поблагодарить Кирилла :). Кирилл, ты у нас первопроходец! И не только в плане самого что ни на есть первого русского вебинара. Я внимательно посмотрел на вебинары наших зарубежных коллег, и вот что оказалось: мы первые, кто показывает на вебинаре case study: не просто презентацию, а живые демки. Впрочем, довольно петь друг другу дифирамбы: недостатков тоже хватало! Как уже сказал Кирилл, ваши отзывы и пожелания принимаются в виде комментариев к этой записи. Заранее спасибо.

Ссылки по теме:
Посмотреть вебинар в записи можно здесь (извините, первые минут 5 «потерялись»).
Исходники проекта Tachyon на разных стадиях оптимизации лежат здесь.
Описание процесса сборки Tachyon.
Скачать триальную версию Intel® Parallel Studio можно здесь.

Всем удачи!

Как мы и обещали, вчера - 26 октября, официально были объявлены победители конкурса «Лето с Intel для профессионального роста». Целую неделю длилось судейство, в котором приняли участие инженеры и менеджеры Intel. Кстати, количество судей было немногим меньше числа участников. Так что оценки каждого хоть и были субъективными, но окончательные результаты на 100% объективны. Те, кто читали конкурсные работы, согласятся, что все проекты «школьников» очень интересные, поэтому выбрать лучшие из лучших было очень непросто. Мы бы с радостью вручили по нетбуку каждому участнику. Но сами понимаете, экономический кризис… да и конкурс предполагает только 3 призовых места. И победителей выбирать нам все-таки пришлось. С довольно большим отрывом определилась явная тройка лидеров:

1 место: Сергей Гризан и Максим Кривов - Разработка примера использования библиотеки Intel® Threading Building Blocks.
2 место: Сергей Лесько - Набор сервисов для предотвращения образования автомобильных “пробок”.
3 место: Наталья Зайцева - Разработка физической модели разбиения твердого тела для игрового движка.

Мои сердечные поздравления победителям и огромное спасибо всем участникам, за то что нашли время принять участие в конкурсе! Ваши работы позволили взглянуть на Летнюю школу с новой стороны, при всех ее многочисленных достоинствах увидеть и недостатки.

Вообще, все члены судейской комиссии были приятно удивлены профессиональным уровнем участников. Кто-то оставлял комментарии к статьям на сайте, кто-то лично нам при сообщении оценок. И мне хотелось бы привести несколько отзывов о работах победителей…и не только победителей. Положительные отзывы читать всегда приятно, и, думаю, все вы с ними согласитесь. Ребята действительно просто молодцы!

Разработка примера использования библиотеки Intel® Threading Building Blocks
Читается легко. Все понятно. Глубина смысла есть, сам давно хотел сделать универсальный асинхронный ввод-вывод, а, оказывается, все уже готово. Спасибо автору!
--Николай Куртов

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

Разработка физической модели разбиения твердого тела для игрового движка
Весьма хорошее теоретическое введение в достаточно специфическую область, а также неплохой практический результат. Возможно работа будет полезна при создании демо-приложений для Larrabee.
--Дмитрий Марочко

Инструмент для поиска потенциальных возможностей проведения кэш-оптимизаций
Еще немного - и уровень статьи для журнала
--Валерий Курякин

Извлечение семантической информации из фотографий
Идея то хороша, да путь к ее реализации весь в терниях, в частности алгоритмы детектирования-распознавания оставляют желать лучшего… это работа не одиночки. Но - желаю успеха!
--Валерий Курякин

Сервис удалённого тестирования производительности ПО на различных программно-аппаратных конфигурациях
Было бы полезно. Ставлю 5 звёзд. Сам думал о такой идее, но несколько меньших масштабов. Доступ к множеству различных платформ имеют единицы, а тестировать было бы полезно.
--Дмитрий Вьюков

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

Всем удачи и роста...профессионального, конечно

Стоит заметить, что 3 ноября будет проведен Онлайн Семинар "Intel(R) Parallel Studio Workflow" на базе Tachyon. Количество участников ограничено.
Первый Шаг в расспараллеливание - это найти наиболее часто используемый участок программы. Для этого использовался Intel(R) Parallel Amplifier. И для сравнения удобства и простоты работы Intel(R) VTune(TM) Performance Analyzer. Как Amplifier так и VTune указали на функции:
grid_intersect и sphere_intersect.

Анализ данных функций показывает, что они не совсем пригодны к распараллеливанию или тюнингу. Соответственно нужно найти либо родительские либо дочерние функции, которые содержат циклы.
Для VTune пришлось собрать профиль Call Graph, на что ушло порядка 13 минут накладных расходов (время работы последовательного варианта Tachyon 30 сек). И 1 час на анализ профиля. У Ampilfier-а использовался уже созданный профиль, что оказалось очень удобным:

В результате мы остановились на кандидате parallel_thread:

static void parallel_thread (void)
{

    unsigned int serial = 1;
	unsigned int mboxsize = sizeof(unsigned int)*(max_objectid() + 20);
    unsigned int * local_mbox = (unsigned int *) alloca(mboxsize);
	memset(local_mbox,0,mboxsize);

    for (int y = starty; y < stopy; y++) { {
        drawing_area drawing(startx, totaly-y, stopx-startx, 1);
        for (int x = startx; x next_frame()) return;
     }

}

И пока я дописываю следующий Блог, предлагаю Вам самим попытаться распараллелить.

Этой осенью совместно с академической программой мы впервые решили провести конкурс среди участников Летней школы Intel. И я надеюсь, вы внимательно следите за его ходом. Хотя, судя по комментариям к статьям, из всех завсегдатаев нашего сообщества в основном только Дмитрий (ksili) и Михаил (mt2) проявляют интерес к работам «школьников».

Если вы пропустили первый пост о конкурсе «Лето с Intel для профессионального роста», еще раз напомню, что участникам предлагалось рассказать о проекте или исследовании, над которым они работали этим летом в Intel, опубликовав техническую статью на нашем сайте.

6 октября прием конкурсных заявок завершился. Уже полным ходом идет судейство конкурса и совсем скоро, 26 октября, будут объявлены счастливые обладатели наших скромных, но очень полезных призов. Всего мы получили 16 статей. Признаюсь, мы рассчитывали на большее количество участников, но видимо слишком многого ожидали от студентов.

Кстати, в этом году среди стажеров Летней школы были также и победители конкурса идей по разработке программных сервисов «Future? At your service!». И во время стажировки они занимались непосредственно реализацией своих идей. Евгений Павлов воплощал в жизнь веб-сервис, предоставляющий возможность извлечения семантической информации из фотографий, Шудрак Максим - сервис удаленного тестирования производительности ПО на различных программно-аппаратных конфигурациях. Интересные идеи и отличные результаты, учитывая, что реализовывать свои проекты ребята начали только в Летней школе. Как полагается, им пришлось составлять и бизнес-план своего проекта, в написании которого очень большую помощь оказал Василий Гурьев. В своей статье «Бизнеc-план IT-продукта: основные проблемы и пути их решения» он рассматривает структуру бизнес-плана и наиболее частые проблемы, возникающие при его написании. Возможно и вы найдете для себя что-то новое и полезное в этом кратком руководстве.

Работы других участников не менее интересны. Очень надеюсь, что у вас будет время почитать все статьи, проголосовать за понравившиеся и задать вопросы участникам в комментариях. И даже если вы уже не студент, вспомните - когда-то и вы им были!

Итак, каждое лето Intel совместно с ведущими ВУЗами нашей страны предоставляет возможность молодым специалистам на практике ознакомиться с мировыми технологиями в области аппаратного и программного обеспечения. В течение целого месяца, пройдя серьезный конкурсный отбор, самые талантливые ребята работают над увлекательными проектами. Причем отрабатывают они свои знания не на выдуманных учебных проектах, а на реальных востребованных проектах компании. Как вы уже догадались, речь идет о Летней школе-стажировке, о которой все вы слышали немало, но, думаю, хотели бы узнать больше. В этом году такая возможность у вас есть!

Как правило, по завершении школы всевозможные пресс-релизы в подробностях рассказывают о самой школе, ее насыщенной учебной программе… но ничего о практической пользе и результатах проектов, над которыми трудились студенты. Не так давно завершилась очередная школа-стажировка. И мы подумали, почему бы не попросить самих студентов снова вспомнить свои стажерские будни и рассказать о проделанной работе. Подумали, и совместно с академической программой решили провести конкурс среди всех участников Летней школы 2009 года. Кстати, от имени Димы Оганезова и своего, конечно, хочу поблагодарить Дмитрия Никитина (aka ksili), который и натолкнул своего тезку на идею этого конкурса. Хотя в своем письме Дмитрий интересовался именно мнением организаторов Летней школы, конкурс среди них мы пока решили не проводить Уверена, сами стажеры с неменьшей информативностью смогут рассказать о поставленных задачах, их роли для проекта и своих профессиональных достижениях.

7 сентября на нашем сайте стартовал конкурс «Лето с Intel для профессионального роста», который продлится до конца месяца. Участникам предлагается опубликовать техническую статью и изложить в ней все подробности своей стажировки. В первой половине октября судейская комиссия оценит все работы, и лучшие из лучших будут награждены ценными призами. Несмотря на то, что в этом конкурсе могут принять участие лишь стажеры летней школы этого года, наверняка, не одному ksili будут интересны работы конкурсантов. Узнать, что же такого полезного могут сделать студенты за 1 месяц стажировки можно на этой странице, где будут размещаться ссылки на статьи всех участников. Прочитав статьи, не забудьте проголосовать за понравившиеся и оставить свои пожелания, замечания, вопросы, в общем, любой свой комментарий к работам. Поддержите наших участников, не зря же они пожертвовали летним отдыхом

О процессорах Intel, наверное, всякий знает. О разработке ПО тоже многие в курсе. Но даже мне, человеку вроде бы посвященному, некоторые ипостаси компании показались неожиданными. Ну, борьба с глобальным потеплением - это вполне логично, не удивили. Нанотехнологии - тоже, у кого они еще такие "нано" в таких масштабах? А вот про TRIL вам что-нибудь слышать приходилось? Technology Research for Independent Living - так это расшифровывается. Не секрет, что население планеты стремительно стареет, и не все пожилые люди по достижению определенного возраста хотят жить с детьми или отправляться в дом престарелых. Многим кажется вполне логичным продолжать самостоятельную жизнь, но как быть, если внезапная слабость или недуг обрушатся, когда рядом никого нет, и до телефона не добраться? Вот в рамках TRIL и разрабатывается комплексное решение для пожилых и самостоятельных. Я его попробовал в действии - чудеса настоящие! Датчики движения по нескольким осям с гироскопом, снятие жизненных показателей с мгновенной отправкой лечащему врачу, предупреждение последнего, если пациент вдруг слишком резко прилег на пол и не двигается, видеосвязь для консультаций, дистанционная выписка лекарств... и все это реально работает! Уже больше десятка стариков используют комплекс в реальной жизни, и, наверное, с ним стало гораздо спокойнее и родственникам, и им самим.

Строго говоря, TRIL - совместный проект нескольких компаний и знаменитого Trinity College, однако Intel играет одну из главных скрипок и выступает в роли финансового партнера.

Завтра прессу проведут по самой FAB 24, а участники из разных общественных организаций и университетов будут рассказывать о своих зонах интересов. К сожалению, разорваться не получится, но, с другой стороны, увидеть производство, где делали отличные материнские платы для моего Pentium II-233, это же счастье. Только надо перед счастьем немного поспать: хоть здесь и на три часа меньше времени, чем в Москве, но организм - не нетбук Acer, ему не только батареи заряжай, но и отдыхать давай.

Эх, до скорого!

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

В общем случае, для подходящего числа 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 ?

Итак начнём. Вообще у меня уже было желание о чём-то таком написать, т.к. здесь уже вопрошали какой же язык наиболее подходит для параллельного програмирования, а какой вообще не подходит... Некоторое время назад я начал изучать язык VHDL и был одновременно обрадован и озадачен. С одной стороны, я увидел - вот он язык для программирования параллельных процессов! Это изначально заложено в самом языке. Но с другой стороны мне было странно, что никто из участников ещё его не упоминал, хотя наверняка ведь знали. Поэтому я решил поизучать его, познакомиться ближе, а потом уже написать в блоге что-то более конкретное.

А тут как раз начался массированный промоушн КА-подхода с стороны одного участника, на форуме ISN было дано несколько ссылок на статьи по теме, и я решил подключиться . Рассуждал я так: конечные автоматы, цифровая схемотехника, RS-триггеры, VHDL... всё это лежит очень близко. А значит точки соприкосновения должны быть найдены. Каково же было моё удивление, когда я в статьях, предложенных автором, не нашёл ни упоминания, ни тем более использования данного языка. Поэтому у меня первый вопрос Вячеславу: Вы знакомы с языком программирования VHDL? Если нет, то вам определённо стоит это сделать! Возможно, когда вы с ним познакомитесь, вы придёте к той мысли, что не надо придумывать никакой КА-модели параллельного программирования. Она уже существует! И реализована в языке VHDL. А ваше желание сделать добро людям трансформируется в более практичные цели:

1) сделать компилятор языка VHDL для архитектуры x86, хотя бы для одной ОС;
2) расширить стандартные возможности языка, чтобы его можно было легче использовать при написании обычных приложений (т.е. библиотеки визуальных компонентов для рисования окошечек и т.д.)

Если же вы знакомы с этим языком, то я очень удивлен, почему в статьях нет упоминания VHDL, а есть какой-то UML? Про UML уже здесь отзывались, да и так известно. Это по большому счёту язык не для написания программ, а для описания моделей. Неплохой инструмент для аналитиков, любителей порисовать картинки, но не для серьёзных программ. Как сказал герой одного фильма: "Ружья для понта, ножи для дела". Как вы поняли, UML - ружья, VHDL (ну или C++) - ножи.

Теперь немного критики по существу.

Во-первых, хотелось бы уточнить то, что касается модели. Вы, Вячеслав:
1) Хотите разработать (или уже разработали) алгоритм, который получает на входе "классический" алгоритм (одно- или многопоточный), а на выходе даёт его аналог, но который внутри действует в форме СМКА?
2) Призываете просто переделывать вручную релизации всех существующих алгоритмов на конечно-автоматную модель?
3) Утверждаете что-то третье...

Что из этого списка ваше?

Во-вторых, что касается модели многопоточного программирования. В форуме кажется высказывался уже подобным образом Алексей Куканов, и я с ним соглашусь. Модель многопоточного программирования вполне понятна: есть основный поток, который может порождать другие потоки, действующие впоследствии параллельно, они тоже могут создавать потомков. И это работает!

В случае OpenMP такое размножение более простое (см. рис.)

Модель параллельных потоков OpenMP

В общем случае может быть и посложнее картинка.

Модель паралельных процессов в общем случае

Так вот в случае КА-модели данный рисунок (т.е. практически это описание модели) будет выглядеть ещё примитивнее: просто постоянно присутствуют N потоков, где N - количество автоматов. Налицо меньшая гибкость модели. Поправьте меня, если я неправ.

Модель потоков в КА-модели

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

Вот здесь я вообще подошёл к наиболее интересному для себя моменту. Охота задать ещё один вопрос Вячеславу. То, как я описал действие КА-модели алгоритма с точки зрения обычного программиста, верно? Т.е. допустим, такая модель для нужного алгоритма есть. Работа каждого автомата независима, значит логика каждого их них реализована в отдельном потоке?

Если мои домыслы верны, то чем принципиально работа такой модели отличается модели многопоточного программирования, которую вы и за параллельное программирование не считаете?

Если же я неправ и поток действительно один, то на самом деле ВОТ ОНО ноу-хау. Фишка в том, как вам удалось запихнуть синхронную работу N независимых автоматов один поток, а сама СМКА-модель - это как раз не новизна (см. выше про VHDL). Если это действительно так, то хотелось бы уточнить для каких случаев удалось добиться такого результата. Хотелось бы верить, что не только для банального RS-триггера.

Идём далее. Понятно, что рисунки выше являются неполными. Потоки не просто работают, они ещё и взаимодействуют. В классическом варианте способы взаимодействия известны: сообщения, события, синхронизированный доступ к данным в памяти какого-то из потоков. В случае СМКА-модели сложность реализации взаимодействия будет зависеть от количества автоматов и от их связности. Ну и конечно от варианта реализации, которые я указал чуть выше: 1 поток или N потоков. Если по одному потоку на каждый автомат, то немало потоков наверно получится, каждый из которых должен ПОСТОЯННО опрашивать выходы тех потоков, которые для него являются входными. Потоки получаются сильно связаными. И не у каждого автомата всего два входа как в пресловутом RS-триггере... В общем, насколько это будет эффективно работать на объемной СМКА-модели, не знаю.

Если же всё в одном потоке (типа ноу-хау), то тут всё зависит от реализации, которую я не знаю. Но вопрос в принципе остаётся тем же: как это можно реализовать для объёмного сложного алгоритма? Всегда ли это будет эффективно с точки зрения скорости?

Ещё пара замечаний (немного критики не по существу):

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

2) Задача о преступниках, описанная в одной из статей, вообще чисто последовательная по условию! К чему там городить параллельность, я не понял.

3) Кроме того, могу в качестве бонуса пояснить, почему я не "очень внимательно прочитал все статьи" (дело не во мне, а в статьях). Но лучше я сделаю это позже, и если сам автор того пожелает. Сначала, хотелось бы обсудить то, что "по существу".

Дальше что-то писать уже, думаю, не стоит. Хотя мысли по данной теме ещё есть. Надеюсь будет повод высказать их в обсуждении.

Я конечно же с интересом продолжил слушать. Вскоре стало ясно, кто рассказчик. Это был Борис Арташесович Бабаян. Он рассказывал о том, какие проблемы возникают при желании повысить производительность вычислительной системы при помощи распараллеливания, о проблемах снижения энергозатрат при вычислениях, о проблемах смены вычислительной архитектуры, о разработанной ими (я так понимаю, под его руководством) технологии двоичной компиляции. Из его слов выходило, что данная технология совершает качественный прорыв в решении упомянутых проблем. Основная её изюминка в том, что компиляция происходит под другую архитектуру, не под ту под которую писал программист, но для него это выглядит прозрачно и ему не надо переучиваться и изучать эту новую архитектуру. Эта самая "другая" архитектура сделана такой, что в ней можно эффективно реализовать отключение питания неиспользуемых блоков. По-крайней мере, так понял я - изложение было очень кратким и вскоре следом уже шёл другой сюжет - про золото (увы).

А теперь попытайтесь отгадать на каком канале я это видел. Это было на телеканале "Культура" (!!!). На телеканале "Культура". Один этот факт меня шокировал, не говоря уже о том, что я был приятно удивлен бодростью Бабаяна и тем как он интересно рассказывал. Вообще-то я когда каналы на телевизоре расставлял, специально поместил Культуру в середине, т.к. смотрю её очень редко, но переключая каналы буду регулярно на неё попадать, и может на что-то интересное наткнусь. Охота оставаться культурным человеком :). Таким же образом я однажды наткнулся на передачу об Арнольде Владимире Игоревиче, ещё одном нашем академике. И если не ошибаюсь, тоже на канале Культура. Парадокс. Кстати в Википедии Бабаян всё ещё член-корреспондент РАН, а ведь он вроде бы уже академик (хотя тут я не уверен). Если тут есть активисты Википедии, приближённые к телу, уточните/поправьте.

Кстати, мне тут недавно пришло письмо с темой ISN TV. Что как нельзя кстати перекликается с вышенаписанным.  Понятно, что можно делать немало видеоматериалов, интересных людям из сферы IT/науки/computer science... Однако на целый телеканал это наверно не потянет, да и даже если потянет, в нашей стране его вряд ли организуют. Интересно, будут ли русскоязычные ролики на ISN TV? У меня эта страница что-то даже не открылась, надеюсь, это из-за наплыва посетителей. Но по ссылке понятно, что она в англоязычной части портала... А ведь есть масса интересного, что можно рассказать именно о "наших". Несмотря на многолетнее отставание отечественной электронной промышленности от мирового уровня, советские/российские специалисты продолжают придумывать в вычислительной технике и IT что-то революционное. Хотя нет, правильнее будет сказать не "специалисты", а "учёные".

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

Причем мне кажется, что пока человек считает, что он ещё может многое изобрести, сделать что-то принципиально новое, он как можно дольше старается оставаться в науке, а не уходить полностью в коммерческие структуры. Взять хотя бы Бабаяна. Наверняка бы его уже много лет назад приняли с распростёртыми  объятиями в массе мест - и в Intel, и в AMD, и в Transmeta, и ещё наверно где-нибудь... однако он до сих пор имеет свою кафедру, хотя и работает в Intel с 2004 года. У меня есть и другой пример - Кадач Андрей Викторович. В 90-е он активно занимался сжатием, писал свои упаковщики, значительно улучшал существующие алгоритмы. Начал он это делать ещё будучи студентом. Итогом была кандидатская диссертация. Кажется она тянула более чем на 200 страниц, убористым почерком. Неслабо для кандидатской. Я ей пользовался. Она и по содержанию очень сильна, особенно в те годы в ней было немало нового. Пару лет назад я был в новосибирском Академгородке, где собственно и учился Кадач, ну и спросил про него. Один человек мне рассказывал, что после защиты диссертации Кадач был завербован Майкрософтом, уехал и больше сжатием не занимается, т.к. одним из пунктов договора было то, что он продолжать свои работы не будет. А занимается он тем, что ездит по миру и вербует таких же как он хороших специалистов. Я не проверял, конечно, этой информации, нет такой возможности.

Возвращаясь к Бабаяну, хочу дать ссылку на его лекцию о работах, которые ведутся с его участием. Интересна она ещё тем, что записана до его перехода в Intel. Когда же мы увидим процессоры и компиляторы Intel в полной мере поддерживающие технологии защищённого программирования и двоичной компиляции? Делаем ставки...