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

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

Можно выделить 2 типа грид-систем:

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

Для создания гридов рабочих станций используется следующее программное обеспечение:

1. системы добровольных вычислений: BOINC, XWHEP, Folding@home
2. системы внутрикорпоративных вычислений: Condor

Для сервисных гридов в свою очередь используется следующее промежуточное программное обеспечение:

1. gLite
2. Globut Toolkit
3. Unicore

В России создано несколько крупных грид-систем: RDIG, РИСП, СКИФ-ГРИД (Unicore). Также наша страна принимает участие в работе и международных, европейских гридов: EGEE (gLite), DEISA.

Ссылки:

gridclub.ru - сайт, посвященный грид-вычислениям

По мотивам лекции "Введение в распределенные и параллельные вычисления", прочитанной М.А. Посыпкиным 25 января 2010 г. в МИИТ.

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

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

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

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

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

Первое, что бросается в глаза, в этом якобы Си-подобном языке, это объявления переменных и типов. Здесь добавлены новые ключевые слова и все перевернуто с ног на голову, команда Go, утверждает, что так удобнее. Но поначалу такое нововведение вызывает только раздражение. Теперь, чтобы объявить переменную i типа int, придется выдать конструкцию:

var i int;

Другие примеры:

var p *int; //указатель
var str string; //строка

Да, да все верно. В Go строки поддерживаются самим языком, мало того, как и в C# они неизменяемые. А значит, при работе с ними придется быть крайне внимательным, чтобы не наплодить кучу строковых объектов.

Арифметике указателей, напротив, придется сказать "до свидания". Гуглы решили, что так безопаснее, да еще и проще будет реализовать сборщик мусора. Ага, в Go появилось и это чудо. Гугл декларирует Go как быстрый язык поддерживающий параллельное программирование. Как сборщик мусора будет сочетаться с этими декларациями? Весьма, весьма интересно. Одно правда, для ряда параллельных задач сборщик мусора упрощает дело. Бывает так, что приходится писать пользовательские менеджеры памяти, только, чтобы память можно было освобождать в условиях общей памяти и многопоточности. С другой стороны, сборщик мусора может серьезно сказаться на эффективности. Задачи дискретной оптимизации, к примеру, весьма активно используют память и сборщик мусора тут может сыграть дурную шутку. Но пока это лишь предположения.

Разработчики Go так и не смогли обойтись без синтаксического сахара в объявлениях переменных, следующие 2 объявления равнозначны:

var i int = 0;
i := int(0);

Оператор := позволяет задавать тип переменной, исходя из типа присваиваемого значения.

Для констант также не нужно задавать тип константы, он определяется по типу значения:

const NewLine = "\n";

Можно объединить определения нескольких констант следующим образом:

const (
	NewLine = "\n";
	MagicNumber = int(7);
)

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

Функции в Go достаточно интересны. Они выдерживают общий стиль объявления новых типов, и на этот раз ключевым словом является func:

func lisa(grade int) {...} // по правилам Си: void foo(int i) {...}
func bart(shorts string) string {...} //const char *bart(const char *str) {...}

Все это конечно замечательно, но есть одно дополнение, которое позволит обходится без boost::tuple в качестве возвращаемого значения:

func homer(beer string) (int, double) {...} //аналог в Си: эээ...
		//int homer(const char *beer, double *result) {...}

В общем, несколько возвращаемых значений не новинка и поддерживаются в том же Руби, но какого их нет в таком вроде новом языке как C#? И в C++ их тоже не хватает. Стандартная ситуация: возврат кода ошибки и основного результата.

Пожалуй не буду дальше испытывать ваше терпение, и некоторые более интересные типы вроде исключений и определений новых типов я оставлю до следующей записи.
P.S.:Для тех, кто как и я страдает без подсветки синтаксиса в Go, могу предложить файл определений для библиотеки GtkSourceView-2.x, если вы скопируете его в папку /usr/share/gtksourceview-2.0/language-specs/ (путь может меняться в зависимости от дистрибутива Linux), то такие приложения как gedit, будут поддерживать подсветку синтаксиса Go: go.lang.

• Сайт языка программирования Go

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

Итак после краткого введения в специфику решаемых задач рассмотрим результаты одного вычислительного эксперимента решения задачи коммивояжёра на МВС-100К:

В столбце "Ускорение" задано ускорение по сравнению с последовательным (однопроцессорном) вариантом. Как легко заметить, практически во всех строках мы наблюдаем сверхлинейное ускорение, кроме строки с числом процессоров равным 32. Мало того, здесь наблюдается еще одна интересная аномалия: задача на 4-х процессорах решается быстрее, чем на 8. Объяснение этой аналомалии мне уже приходилось давать:

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

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

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

Мы можем видеть, что ни о каком сверхлинейном ускорении и речи быть не может.

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

Перед тем, как привести пример работы технологии, придется рассказать о недавно добавленной поддержке замыканий в C/C++/Objective-C под называнием "блоки". Блоки объявляются с помощью нового оператора ^:

int i = 5;
testb = ^(char *s) { printf("string is %s, number is %d\n", s, i); };
testb("hello");

Результатом вызова в 3-й строке будет:

string is hello, number is 5

Подробнее о блоках мы можете почитать в википедии: Блоки (расширение языка Си).

Итак, на входе у нас имеется следующий последовательный код:

for (i = 0; i < count; i++) {
      results[i] = do_work(data, i);
}
total = summarize(results, count);

При условии, что функция do_work не изменяет какие-либо глобальные переменные, мы можем распараллелить с помощью OpenMP:

#pragma omp parallel for
for (i = 0; i < count; i++) {
      results[i] = do_work(data, i);
}
total = summarize(results, count);

А при использовании GDC код будет выглядеть так:

dispatch_apply(count, dispatch_get_global_queue(0, 0), ^(size_t i){
     results[i] = do_work(data, i);
    });
total = summarize(results, count);

Почувствуйте, что называется разницу. На самом деле разница, конечно, есть. Технология Apple имеет более широкое применение, к примеру, задачи мы можем запускать не только параллельно, но и асинхронно (dispatch_async), а также запускать в определенное время (dyspatch_after). Таким образом, GDC поддерживает не только параллельные вычисления, но обеспечивает новый способ добавления асинхронности в приложения. Притом этот способ действительно выглядит весьма прозрачным и простым, как утверждает Apple. Мало того, Apple обещает, что создание и запуск задачи будет требовать очень мало ресурсов, намного меньшие чем создание и запуск потока.

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

Что интересно, Apple выпустила GCD под открытой лицензией Apache, и в данный момент эта технология уже портирована на FreeBSD (см. [1]).

Ссылки:

1. libdispatch
2. Wikipedia: Grand Central Dispatch
3. Wikipedia: Блоки (расширение языка Си)
4. Поддержка замыканий в Snow Leopard

P.S. По этой теме я перевел 2 статьи англоязычной википедии про GCD и Blocks, и понятное дело, разместил их перевод в русской википедии. В ходе перевода пришлось сделать ряд допущений, к примеру, Blocks перевел как блоки, а Task Parallelism - параллелизм задач (есть вариант параллелизм заданий). В общем, я усиленно намекаю что, критика перевода и особенно его улучшение приветствуются.

Тематика блога вряд ли будет отличаться от моих интересов: технологии параллельных вычислений MPI, OpenMP, CUDA, PThreads и пр.

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

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

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

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