Стоит заметить, что 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;
     }

}

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

Технологиия изготовления блогов, в общем-то, проста. У Анатолия Александровича есть личная видеокамера компании XXX (нет бесплатному навязчивому пиару торговых марок!), отличающаяся весьма компактными размерами. Она путешествует с владельцем по России и Украине. Наговорив в объектив определенное количество монологов, Вассерман переправляет их в редакцию - или на флэшке "живьем", или через ftp. Далее я конвертирую исходные файлы в формат, пригодный для сайта, и вуаля, можно смотреть!

По ряду причин, нам подходит только конвертер Moyea Flash Video MX Pro. Я уже не раз и не два ругал его в этом блоге, и главным образом - за упорное желание работать только на одном ядре. Но вот вчера, тестируя новый казенный ноутбук Acer 5737Z, я решил не включать Главный Домашний Компьютер и пережать новые монологи Анатолия Александровича силами мобильного Pentium Dual-Core. Запустил процесс - и чуть со стула на упал: Task Manager явно демонстрировал, что конвертер грузит ОБА ЯДРА! Тут уж пришлось включать Главный Компьютер, где стоит та же версия конвертера и операционной системы, и вновь убеждаться, что на Core i7 продолжает использоваться только одно ядро из четырех возможных. Впрочем, как и на редакционном Core 2 Quad. Запускаю снова конвертацию на ноуте - вуаля, пашут оба ядрышка.

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

Кстати, 3.2-гигагерцовый Core i7 одним ядром жмет в два с лишним раза быстрее, чем 2.18-гигагерцовый Pentium Dual-Core двумя. И не только Вассермана.

Идея не моя, я её всего лишь вспомнил и развил. В выходившем некогда журнале Game.EXE была рубрика с письмами от читателей. В одном из них (где-то за 2004-05 год) излагалась примерно такая идея (возможно, она родилась под впечатлением от парочки новых на то время 3D-игр, но тем менее). Сейчас уровень развития движков 3D-игр таков, что позволяет генерировать на экране картинку очень близкую к реальной, при этом с неплохим fps. Почему бы не начать делать фильмы на основе этих движков? То есть зритель уже не будет довольствоваться тем, что ему покажет одна-единственная камера, а сможет, например, наблюдать один и тот же эпизод глазами разных персонажей. Предполагалось, что это позволит глубже понять задумку режиссера и то, почему в некоторых ситуациях разные персонажи совершают определённые поступки.

Разумеется для этого придётся неоднократно отматывать видео назад, что представляется не очень удобным. Но здесь пока идет речь не об удобстве. Как показывает опыт (Apple, например), работу в любой системе можно сделать приятной и удобной.

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

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

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

P.S. Кстати уже после того как это написал, обнаружил, что Intel совместно с некоторыми организациями с громкими названиями проводит конкурс по применению высокопроизводительных вычислений («МАКСИМАЛЬНАЯ МАСШТАБИРУЕМОСТЬ – 2009»). Вроде то, что я тут изложил туда бы пошло. Вот только там нужны уже реальные проекты, а у меня пока только идея. Странно, что на форуме и блогах ISN нет никакой информации об этом конкурсе, и даже письма никакого не прислали. Хотя однажды мне (в ответ на моё письмо) обещали, что будут извещать о конкурсах и других мероприятиях в академической программе Intel, в которых я смогу принимать участие.

Кстати, там почему-то на разных сайтах разная информация о призах для победителей. Вот здесь - 250000 руб и 12500 руб, а вот здесь - 350000 и 150000 руб.

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

Когда нам поставили задачу эффективно использовать 2 ядра, декодер содержал только последовательный код. Чтобы сделать декодер многопоточным предстояло полностью переписать его внутреннее устройсто.
Мы пошли по пути наименьшего сопротивления. Т.к. процесс декодирования видео стандарта H264 состоит из нескольких независимых этапов, самого декодирования и процесса исправление ошибок квантизации - «деблокинга», первое решение было сделать так, чтобы эти этапы выполнялись в разных потоках. От нас практически не потребовалось вносить в декодер какие-либо значительные изменения. Этот способ параллелизации дал декодеру существенное ускорение при использовании второго процессора, однако до заветных 2х было ещё далеко. К тому же, нагрузка на ядра процессора, при использовании этого способа параллелизации, сильно зависела от настроек кодирования видеопотока, использования особенностей стандарта и варьировалась в широких пределах.

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

На следующем этапе параллелизации нам пришлось провести декомпозицию процесса декодирования по данным. Это потребовало практически полной переписки декодера, но мы рассчитывали получить впечатляющие результаты. Теперь рабочий поток получал для обработки не целиком слайс, а только одну строчку макроблоков из него. К тому же, поток выполнял не полное декодирование переданной ему строчки, а только часть: декомпрессию данных макроблоков или реконструирование макроблоков, используя ранее декомпрессированые данные. Данные макроблоков декомпрессировались в специальные временные буфера, откуда позже использовались для реконструирования. Процесс деблокинга также был подвергнут процессу декомпозиции по данным. Теперь оба рабочих потока могли выбирать на исполнение любую их 3х задач (декомпрессию, реконструкцию, деблокинг), в зависимости от текущей стадии декодирования кадра. И хотя этот способ оказался непременим при декодировании некоторых видеопотоков, сжатых с использованием особенности slice group стандарта H264, в целом он продемонстрировал отличную производительность. Теперь декодер легко показывал двукратное ускорение при декодировании любых видеопотоков.

На самом деле, я немного слукавил, описывая первые три этапа параллелизации, когда говорил «любые видеопотоки». Я имел ввиду потоки большого разрешения. Больше, чем стандартное телевизионное (SD, 720x576) разрешение. Когда мы попытались протестировать декодер на видеопотоках с маленьким разрешением, мы наткнулись на неприятный сюрприз: не было никаких признаков двукратного роста производительности при использовании второго потока. Максимум, что показывал декодер – было 30ти процентное ускорение, что было полностью неприемлимо для нас. Дальнейшее расследование выявило несколько проблем, которые полностью отсутствовали при декодировании видеопотоков с большим (HD, 1920x1080, 1280x720) разрешением. Решение этих проблем стало залогом к блестяще работающей параллелизации.
Сначала мы избавились от лишних обновлений кэша ядер процессоров. Дело в том, что выполняя реконструирование макроблоков, рабочие потоки использовали временные буфера для хранения промежуточных данных, что вызывало лишние принудительные обновления кэша у второго ядра. Мы переписали функции, выполняющие реконструирование, чтобы они не «портили» данные во временном буфере, а использовали стэк для хранения промежуточных данных. Принудительные обновления кэша ядер исчезли, что положительно сказалось на общей производительности, но конечная скорость работы декодера по-прежнему была неприемлима.

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

Первоначальная схема синхронизации

Конечная схема синхронизации

Зависимая декомпрессия опорных кадров

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

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

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

А именно, недавно мне пришлось походить по компьютерным магазинам Нижнего Новгорода - типичного крупного российского города. Так вот, оказалось, что во всех магазинах - начиная от дорогого сетевого  "Белого Ветра" и заканчивая мелкими безвестными магазинчиками, примерно одна и та же картина: большие компьютеры (десктопы) стыдливо засунуты в самые дальние углы и под прилавки, а на виду расположились всевозможные ноутбуки -от больших "дескноутов" до компактных "нетбуков". И найти среди них модель с дискретной видеокартой, либо с интегрированной графической картой НЕ Интел не так просто. Это будет примерно одна модель из четырех-пяти.  Все остальные девайсы содержат Intel GMA, т.е. интегрированную графику Интел. Так что не учитывать ее при выпуске новых игр сейчас никак нельзя.

Кроме того, теперь я могу гораздо лучше ответить на повторяющийся в ходе каждого моего выступления вопрос из зала: "А какие игры идут на вашей интегрированной графике?".  Если еще год назад я могла сказать только то, что на IGFX работает 95% игр выпуска до 2004 года, а список современных игр, совместимых с IGFX, можно найти на сайте интел (http://www.intel.com/support/graphics/sb/cs-012643.htm).  Причем, на самом деле списков - несколько, свой для каждого семейства интегрированных карт и ОС (Win ХР -Vista). Но, хотя в среднем в этом списке присутствует более 40 игр, назвать его полным и даже почти полным никак нельзя. Дело в том, что игр на рынке ну очень много, кроме того, постоянно появляются новые, так что протестировать их у инженеров Интел нет никакой возможности. Хотя, для кого-то, конечно, это была бы работа мечты - получать зарплату за тестирование игр, но, увы, такой должности нет в штатном расписании Интел.

Но, оказывается, есть люди, занимающиеся тем же самым независимо от Интел, совершенно бесплатно, - для своей пользы и удовольствия. Недавно мне показали сайт, точнее блог (на русском языке!) с говорящим названием -http://games4intelgma.blogspot.com/

Автор блога, незнакомый мне, и, насколько я понимаю, никак не связанный с Интел, протестировал на совместимость с Intel GMA множество игр , и по результатам составил свой список, который постоянно пополняется, причем, не только усилиями самого автора, но и читателями блога - так называемый "народный список".  В сумме эти списки почти вдвое длиннее представленных на сайте Интел. Но, конечно же, и они не являются полными. Поэтому теперь я буду давать адрес этого блога всем желающим, предлагая дополнить их своими находками.

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

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

Приведем результаты замеров для разного количества потоков. В каждом случае производилось 10 запусков синтетического теста и выбиралось минимальное время работы.

Из графика видно, что на 4-5 потоках синтетический тест достигает своей пиковой производительности.

На тестовой машине установлена  3х-канальная DDR3 память с пиковой нагрузкой в 32 Гб/c. Вряд ли мы ее превысили. С большей степенью вероятности, причина спада производительности на большем количестве потоков заключается в том, что наш Core i7 содержит всего 4 физических ядра. И уже при больше, чем на 4 потоках, они начинают делить между собой ресурсы процессора, вызывая тем самым нежелательные кэш эффекты.

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

enum
{
BLOCKSIZE                   = 1024 * 1024 * 256,
ITER                        = 128,
ALIGN                       = 64
};

typedef unsigned char byte;

int main(int argc, char **argv)
{
byte *mem, *pBuf = new byte [BLOCKSIZE + ALIGN];
LARGE_INTEGER start, stop, freq;
__int64 temp;
int timePerBlock;
int mbPerSec;

SetThreadAffinityMask(GetCurrentThread(), 2);

mem = (byte *) ((((size_t) pBuf) + ALIGN - 1) & -ALIGN);
memset(mem, 0, BLOCKSIZE);

// start timing
QueryPerformanceCounter(&start);

for (int i = 0; i < ITER; i++)
{

__asm
{
mov ecx, BLOCKSIZE
mov esi, dword ptr [mem]
pxor xmm0, xmm0

jmp NEXT

ALIGN 10h
RESTART_LOOP:
#if 0
// read speed test
movdqa xmm0, oword ptr [esi + 000h]
movdqa xmm1, oword ptr [esi + 010h]
movdqa xmm2, oword ptr [esi + 020h]
movdqa xmm3, oword ptr [esi + 030h]
movdqa xmm4, oword ptr [esi + 040h]
movdqa xmm5, oword ptr [esi + 050h]
movdqa xmm6, oword ptr [esi + 060h]
movdqa xmm7, oword ptr [esi + 070h]
movdqa xmm0, oword ptr [esi + 080h]
movdqa xmm1, oword ptr [esi + 090h]
movdqa xmm2, oword ptr [esi + 0a0h]
movdqa xmm3, oword ptr [esi + 0b0h]
movdqa xmm4, oword ptr [esi + 0c0h]
movdqa xmm5, oword ptr [esi + 0d0h]
movdqa xmm6, oword ptr [esi + 0e0h]
movdqa xmm7, oword ptr [esi + 0f0h]
#else
// write speed test
movntdq oword ptr [esi + 000h], xmm0
movntdq oword ptr [esi + 010h], xmm0
movntdq oword ptr [esi + 020h], xmm0
movntdq oword ptr [esi + 030h], xmm0
movntdq oword ptr [esi + 040h], xmm0
movntdq oword ptr [esi + 050h], xmm0
movntdq oword ptr [esi + 060h], xmm0
movntdq oword ptr [esi + 070h], xmm0
movntdq oword ptr [esi + 080h], xmm0
movntdq oword ptr [esi + 090h], xmm0
movntdq oword ptr [esi + 0a0h], xmm0
movntdq oword ptr [esi + 0b0h], xmm0
movntdq oword ptr [esi + 0c0h], xmm0
movntdq oword ptr [esi + 0d0h], xmm0
movntdq oword ptr [esi + 0e0h], xmm0
movntdq oword ptr [esi + 0f0h], xmm0
#endif

add esi, 100h
sub ecx, 100h

NEXT:
cmp ecx, 0
jne RESTART_LOOP
}

}

// finish timing
QueryPerformanceCounter(&stop);

QueryPerformanceFrequency(&freq);

timePerBlock = (int) ((stop.QuadPart - start.QuadPart) * 1000 * 10 / (freq.QuadPart * ITER));
printf("msec : %d.%d\n", timePerBlock / 10, timePerBlock % 10);

temp = ITER * (BLOCKSIZE / (1024 * 1024));
temp *= freq.QuadPart;
temp /= (stop.QuadPart - start.QuadPart);
mbPerSec = (int) temp;
printf("mb/s: %d\n", mbPerSec);

delete [] pBuf;

return 0;
}

Таким образом можно вычислить фактическую пропускную способность памяти. Мне хочется верить в это ?. На тестовой конфигурации получаем 7 gb/s на запись и 11 gb/s на чтение.

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

Как часто бывает, синтетический тест оказался далек от жизненных реалий. Практика опять разошлась теорией.

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

Остановимся подробнее на задаче о гравитации. И начну я, как всегда, обстоятельно и издалека :).

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

Гравитация была первым взаимодействием, описанным математической теорией. В рамках классической механики, гравитационное взаимодействие описывается законом всемирного тяготения Ньютона, который гласит, что сила гравитационного притяжения между двумя материальными точками массы m1 и m2, разделённых расстоянием r есть

Где G - гравитационная постоянная, равная -6,673e-11 м2/(кг с2). Знак минус означает, что сила, действующая на тело, всегда противоположна по направлению радиус-вектору, направленному на тело, т. е. гравитационное взаимодействие всегда приводит к притяжению любых тел.

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

Наиболее простой задачей небесной механики является гравитационное взаимодействие двух тел в пустом пространстве. Эта задача решается аналитически до конца и результат её решения часто формулируют в виде трёх законов Кеплера.

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

Общая задача n-тел описывается системой дифференциальных уравнений следующего вида:
Где mi, ri и vi - масса, радиус-вектор и скорость i-го тела соответственно (i изменяется от 1 до N). Массы тел, а также положения и скорости в начальный момент времени считаются известными. Необходимо найти положения и скорости всех частиц в произвольный момент времени, т.е. полностью определить эволюцию системы N гравитирующих тел.

Но мы с вами рассмотрим частный случай (идеализацию) задачи N тел. При исследовании гравитационного взаимодействия между планетами Солнечной системы и космическим объектом, очевидно, можно исключить из рассмотрения силы, действующие со стороны объекта на планеты, ввиду его несравнимо малой массы mс. Также примем, что наибольшее воздействие на траекторию движения объекта оказывают две ближайшие планеты с массами m1 и m2. Радиус-векторы планет определяются как r1 и r2, соответственно.

Запишем второй закон Ньютона для данной системы тел:

Распишем действующие гравитационные силы:

Сокращая на mc и переходя к дифференциалу получим:

Таким образом, уравнения определяющие эволюцию движения космического объекта будут выглядеть следующим образом:

Широкий спектр физических явлений описываются производными второго порядка. Процесс гравитации не исключение.

Существуют различные методы численного решения дифференциальных уравнений. Все они отличаются вычислительной сложностью и точностью. Метод Эйлера – один из самых простых и неточных вычислительных методов. Построим схему метода.

Рассмотрим непрерывную функцию x(t)  и ее изменения с течением времени. Начиная с начального значения x0, можно вычислить следующее значение функции x1 используя уравнение производной функции. Формально производная определяется следующим образом:

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

Второе слагаемое уравнения есть не что иное,  как первый член разложения функции в ряд Тейлора в точке ti. Данная схема для численной аппроксимации решения дифференциальных уравнений была придумана Леонардом Эйлером.

Применим данную схему к нашей задаче и вычислим новые координаты и скорости объекта. Согласно схеме формулы выглядят следующим образом:

Для вычислений необходимо спроектировать эти уравнения на оси координат. Спроектируем силы на Oxyz:

Запишем, в качестве примера, вычисление следующего значения абсциссы точки:

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

Для графической визуализации используется библиотека OpenGL.

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

struct SolidSphere
{
double coord[3];
double velocity[3];
double mass;
double radius;
};

Функции, отвечающие за проецирование гравитационных сил на оси координат Oxyz:

double fx (double mass, double x, double y, double z, double xp, double yp, double zp)
{
return  mass*(xp-x)/(pow(pow(x-xp,2)+pow(y-yp,2)+pow(z-zp,2),1.5));
}

double fy (double mass, double x, double y, double z, double xp, double yp, double zp)
{
return  mass*(yp-y)/(pow(pow(x-xp,2)+pow(y-yp,2)+pow(z-zp,2),1.5));
}

double fz (double mass, double x, double y, double z, double xp, double yp, double zp)
{
return  mass*(zp-z)/(pow(pow(x-xp,2)+pow(y-yp,2)+pow(z-zp,2),1.5));

}

Численный метод, решающий дифференциальную систему уравнений:

satellite.velocity[0] = vx  + dt*(fx(m1, x, y, z, x1, y1, z1) + fx(m2, x, y, z, x2, y2, z2) + fx(m3, x, y, z, x3, y3, z3));
vx = satellite.velocity[0];
satellite.coord[0] = x + vx*dt;

satellite.velocity[1] = vy  + dt*(fy(m1, x, y, z, x1, y1, z1) + fy(m2, x, y, z, x2, y2, z2) + fy(m3, x, y, z, x3, y3, z3));
vy = satellite.velocity[1];
satellite.coord[1] = y + vy*dt;

satellite.velocity[2] = vz  + dt*(fz(m1, x, y, z, x1, y1, z1) + fz(m2, x, y, z, x2, y2, z2) + fz(m3, x, y, z, x3, y3, z3));
vy = satellite.velocity[2];
satellite.coord[2] = z + vz*dt;

Задавая различые начальные условия Коши получаются различные траектории движения:

рис.1 Траектория движения объекта под действием двух статических масс

рис.2 Траектория движения объекта под действием одной статической массы

рис.2 Траектория движения объекта под действием одной статической массы

Вот как то так Осталось только зайти в нижегородский планетарий и посмотреть как космические корабли бороздят просторы большого театра Вселенной, под радостные крики и слезы счастья местной ребятни. I’m so proud

Надеюсь, было интересно

А на дорожку - о занимательной статистике. На прошлой неделе мы запустили опрос на Computerra.ru - "Применяете ли вы GPU в неигровых задачах?". Проголосовало относительно немного людей, всего 852, но с учетом специфики нашего портала - выборка вполне и вполне.

Итак, чуть менее 7 процентов участников опроса (58 человек) используют GPU только для пережима видео. Около 10 процентов (84 опрошенных) ответили, что применяют видеокарту "для самых разных видов расчетов, GPU не простаивает". 17 с половиной процентов (149 респондентов) еще не пробовали использовать GPU не по назначению, но обязательно попробуют. Еще 21 процент (180 граждан) грустно сказали, что и в игровых-то задачах ничего такого не пользуют. Наконец, самый популярный ответ оказался... шуточным. Мы всегда придумываем такой, дабы внести элемент здорового раздолбайства, и в этот раз шутка удалась: 372 человека, или 42 процента опрошенных, ищут... способы запуска Linux на GPU.

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

Хороших всем выходных. Лично я отдыхать не собираюсь, потому что дома лежит двухтерабайтный винчестер Westtern Digital и про него надо написать статью. Эх, до сих пор помню, как в 97-м году мой состоятельный товарищ купил себе винт емкостью 6.4 гигабайта. А я две недели ходил и спрашивал знакомых: ну куда такой монстрила? Что на нем хранить? Чем забивать? Это ж нереал какой-то. Теперь, спустя 12 лет, мне и два терабайта кажутся не ахти каким объемом. Готов на спор забить за полгодика. А вы?

Отлично. Как раз имеется прекрасная задача, которая идеально ложится на архитектуру многоядерности современных GPU. Речь идет о вычислительно сложных алгоритмах оценки движения (motion estimation), краткий курс в которые был изложен в предыдущей статье.

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

Рассмотрим изображение состоящее из N x M макроблоков (16х16). Алгоритм полного поиска (Full Search) производит поиск наиболее похожего макроблока в некоторой области, называемой окном поиска, размером (2x + 1) х (2y + 1) макроблоков. Тогда формула для нахождения искомой величины с учётом краевых эффектов выглядит следующим образом:

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

Не вдаваясь в детали, приведем лишь цифру в почти 9 миллионов сравнений для кадра размером 1920x1088 и минимальным окном поиска в 1 макроблок. А ведь опорных кадров может быть несколько, да и область поиска в 1 макроблок слишком мала. Таким образом, цифра получается впечатляющая. Зная точное количество сравнений макроблоков возможно рассчитать количество микроопераций процессора.

А что из себя представляет сравнение макроблоков?

Одно сравнение есть не что иное, как вычисление критерия SAD (Sum of Absolute Difference) между макроблоками в исходном и опорном изображении.

Таким образом, приблизительно (очень приблизительно :)) 1279 операций тратится на одно сравнение двух макроблоков размером 16x16. Умножаем на общее количество сравнений и получаем искомую цифру.

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

Последние поколения GPU процессоров являются программируемыми. Они состоят из множества потоковых исполнительных устройств, которые исполняют различные программы, называемые ядрами (kernels). Потоковые исполнительные устройства могут производить вычисления общего назначения, используя модель вычислений SIMD (Single Instruction Multiple Data). В этой модели программирования, входящие массивы данных хранятся в памяти, отображаемой на некоторое количество исполняемых устройств, которые, исполняя пользовательские программы-ядра, генерируют выходные данные, и те в свою очередь записываются назад в память. Каждый экземпляр программы-ядра, запускаемый на SIMD процессоре, называется нитью (thread).  Определенный прямоугольный регион выходного буфера, на который отображаются нити, называется исполняемым регионом (domain of execution). Потоковый процессор распределяет массив нитей по группам, пока все нити не будут распределены. Затем программы-ядра могут начинать вычисления, используя вычислительные ресурсы каждой из этих групп. Упрощенная схема данной модели вычислений представлена на рисунке на примере решения AMD.

Производители графических адаптеров предоставляют весь необходимый инструментарий для программирования GPU. NVIDIA поставляет CUDA, а AMD - Stream SDK.

Оба решения предполагают две модели использования: программирование GPU используя расширение языка C и native использование. В первом случае код небходимо предварительно скомпилировать в родной ISA (Instruction Set Architecture). Для этого NVIDIA и AMD поставляют специальные компиляторы. Мне удалось попробовать данный подход в рамках обоих продуктов и CUDA показала себя с лучшей стороны. Технология представляется мне более стабильной и завершенной. Второй подход подразумевает под собой использование run-time функций библиотеки. Здесь необходимо работать с такими понятиями как девайс, контекст, вручную загружать данные в ту или иную область видео памяти,  подгружать функцию-ядро и запускать ее на выполнение. Так как в данном случае мы имеем возможность выбирать тип памяти (текстурная, разделяемая, глобальная) и писать ядра на родном ISA видео процессоров, второй подход имеет смысл использовать для полной выжимки возможностей GPU.

И конечно же, было невозможно пройти мимо Larrabee. За счет гетерогенной архитектуры Larrabee код, предназначенный для выполнения на видеокарте, представляет собой привычный всем CPU совместимый код, написанный на языке C/C++. Все, что остается сделать, это перенести нужную функциональность и представить ее в виде исполняемого модуля для Larrabee, а также передать данные для обработки на видеоадаптер.

Последнее достигается путем создания специальной прослойки между приложением и кодом, исполняемым на дискретной карте. Данная прослойка базируется на Intel Larrabee Native SDK, который предоставляет весь необходимый функционал для написания приложений: загрузка и конфигурирование исполняемых модулей Larrabee, передача исходных данных на графическую карту и приём готовых конечных данных с графической карты.

В результате Larrabee версия заняла меньше всего времени на разработку и оказалась наиболее приятной платформой для использования возможностей GPU. К сожалению, не имею права приводить какие либо цифры и детали реализации.

В заключение хочется сказать, что "не так страшен черт, как его малюют". Писать код под GPU было интересно и местами даже забавно. Особенно было забавно тратить несколько дней на поиск ошибки в своем GPU коде, а в результате это оказывалась ошибка в драйвере и вас в очередной раз просили откатиться на предыдущую версию или поставить апдейт. Нужно всегда с подозрением относиться к ошибкам и использовать CPU эмуляцию или собственную CPU реализацию алгоритма. С ее помощью я обнаруживал ошибки в работе драйвера и портил жизнь support службе одной известной компании.

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

]]> http://software.intel.com/ru-ru/blogs/2009/06/10/gpu-cuda-stream-sdk-amp-larrabee/feed/ http://software.intel.com/ru-ru/blogs/2009/06/03/2001472/ http://software.intel.com/ru-ru/blogs/2009/06/03/2001472/#comments Wed, 03 Jun 2009 18:33:43 +0000 Dmitry Oganezov (Intel) http://software.intel.com/ru-ru/blogs/2009/06/03/2001472/ Всем привет!

Думаю, мне стОит иногда отвлекаться от конкурсов, а то что ж это я… Массовик-затейник, что ли? Так вот, о чем хотел сказать…

Мы тут всё рассуждаем о высокопроизводительных вычислениях, математике, оптимизации, HPC (не к вечеру будь они помянуты), скоростной передаче данных, и прочих хитромудрых новоизобретениях. Недавно Вильянов проводил сбор мнений «что бы было, если бы у вас был беспроводной безлимитный Интернет со стремящейся к бесконечностью скоростью». Да ничего бы не было! По крайней мере, кроме видео-трансляций с нудистских пляжей никаких идей у сообщества не появилось. Впрочем, и с пляжем нужно еще разобраться: очень я опасаюсь, что в силу ряда причин трансляции эти не станут мега популярными…

И все-таки, давайте пофантазируем! Вопрос мой звучит так: «что бы было, если бы у вас были неограниченные вычислительные мощности при стремящих к нулю тепловом пакете и цене?». Нет, правда… Уже сейчас за каких-нибудь пару десятков тысяч долларов вы можете прикупить себе не-скажу-какой компьютер с производительностью 4 TeraFlops и, вероятно, попадете с ним вот в этот список. Кроме почетного места в списке, практической пользы от этого ящика в домашнем хозяйстве не будет – только вред один. Что на нем считать-то? Есть идеи?

У меня сегодня утром появилась одна, спешу поделиться. Перед тем как читать дальше, давайте условимся: если заработаете на ней бессовестно много денег, вы потом в мемуарах напишите, что это, мол, вас Дмитрий c ISN надоумил. Пустяк, а мне приятно. Впрочем, вам еще рано думать о мемуарах.

Итак, идея. Собственно, это комбинация двух идей. Microsoft продемонстрировал концепт Natal на GamesSpot E3 v.2009. Видео стОит тысячи слов, но если коротко, то это система взаимодействия с компьютером (в данном случае – с игровой приставкой), основанная на распознавании 3D образа пользователя. Проше говоря, вы делаете вид, что пинаете мяч, а компьютер распознает, что вы как бы пинаете как бы мяч. В результате виртуальный мяч летит туда, куда вы его как бы пнули. Видео:

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

Объединяем две идеи и смотрим, что получилось. А получился у нас  домашний медиа-центр воспроизводящий HD видео с расширенными возможностьями управления на основе распознавания 3D образа зрителя. Представили? Пока нет? Поясняю: никаких пультов ДУ, никаких кнопок… Сидя в кресле перед 50” телевизором 1080p, вы ловите летящий в ворота мяч выверенным движением руки, медиа-центр тут же рисует траекторию полета (масштабируя картинку при необходимости), и вам остается только переместить воображаемый мяч в нужную точку рукой, чтобы посмотреть еще раз тот самый удар Аршавина. Круто? Принимайте заказ на разработку!

Традиционно всем удачи и побольше терафлопов.

PS: Специально для Сергея Вильянова: да, да, и еще раз да. Все это прекрасно ложится на идею прямой трансляции видео с нудистских пляжей, по WiMax.