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

После заполнения его каким-либо способом (зависит от библиотеки распараллеливания), загружаем данные в память видеокарты вызовом glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA...), а затем отрисовываем одним блоком GL_QUADS на весь экран (выводим прямоугольник).

Вариант с glDrawPixels и так не советуют к использованию, так еще и по результатам эксперимента применение данной функции приводит к падению скорости отрисовки на порядок. Не пойдет. А применение VBO (Vertex Buffer Objects) в данном случае не обосновано - у нас всего 4 вершины и одна текстура.

На выбор OpenGL+GLUT прежде всего повлияло желание собрать и запустить приложение как под Linux, так и под Windows и сравнить результаты на одинаковом "железе".

Распараллеливание будем выполнять, разделив текстуру на горизонтальные блоки по числу используемых потоков/ядер. В SLI/CrossFire конфигурациях видеокарт используется подобный режим Split Frame/Scissor (изображение взято с википедии):

Заменим видеокарты на процессорные ядра - и получим вариант распараллеливания.

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

typedef struct {
    double x1, y1,
           x2, y2;
} Bounds;

typedef unsigned char byte;

typedef struct {
    int  width,     // ширина в пикселях
         height,    // высота в пикселях
         size;      // размер в пикселях == width*height
    byte *buff;     // кусок памяти с пиксельными данными
} Buffer;

Само множество на комплексной плоскости находится в пределах (-2,-1) x (1,1), так что можно начать с вывода с запасом (-2,-1.5) x (1,1.5) - вариант квадратной области.

Текстура хранится также квадратная, размерами 2^n (текстуры размерами не кратными степени 2 будут работать далеко не на всех видеокартах). Размер текстуры (T), равно как и предельное число итераций проверки сходимости (n) выражают общую сложность построения как O(T^2*n).

При распараллеливании каждому из потоков на вход нужно подать ограничивающий объем в координатах комплексной плоскости, а также две V-координаты текстуры (высота/ось Y), обозначающие первую и последнюю строки, в которых следует отобразить результаты.

Сразу картинку возможного вывода:

Итого имеем:

// координаты "окна" в комплексной плоскости
Bounds screen;

// текущие координаты центра "окна" в комплексной плоскости
double cX=0, cY=0;

// размер клиентской области окна в системе
int window_width  = 800,
    window_height = 800;

// текущий шаг приближения
int STEP = 0;

// предел числа итераций проверки сходимости
int ITERS = MIN_ITERS;

Собственно рендер фрактала в текстуру выполняется обычным распараллеленым циклом:

void fractal() {
    int parts = omp_get_max_threads();
    if ( parts <= 0 ) parts = 1;

    omp_set_dynamic( 0 );
    omp_set_num_threads( parts );

    int p, y=0, dy;
    double sy = (screen.y2-screen.y1) / parts;
    dy = buffer.height / parts;

    #pragma omp parallel for firstprivate(y) ordered
    for ( p=0; p<parts; ++p ) {
        Bounds bounds;
        bounds.x1 = screen.x1;
        bounds.x2 = screen.x2;

        bounds.y1 = screen.y1 + p*sy;
        bounds.y2 = bounds.y1 + sy;

        y = p*dy;

        //fractal_block( bounds, y, y+dy-1, (p+1)*6 );
        fractal_block( bounds, y, y+dy-1, 3 );
    }
}

Т.к. координата верхней строки каждого блока (y) используется внутри тела цикла, при этом меняясь, то ее следует передавать через firstprivate.

Функция fractal_block принимает координаты окна комплексной плоскости (bounds), верхнюю и нижнюю границы в текстуре (y, y+dy-1) и множитель "яркости" (о нем ниже):

void fractal_block( Bounds block, int y1, int y2, int f ) {
    int *ptr = (int*)( buffer.buff + y1*buffer.width*4 );

    double x, y, sx, sy, z, zi;

    x = block.x1;
    y = block.y1;
    // приращения по комплексным осям между соседними текселями текстуры
    sx = (block.x2 - block.x1) / buffer.width;
    sy = (block.y2 - block.y1) / (y2-y1+1);

    int width = buffer.width;

    // раскидываю значение множителя по трем младшим байтам
    f = f%256;
    f = (f<<16) | (f<<8) | f;

    for ( ; y1<=y2; ++y1 ) {
        int _x;
        for ( _x=0; _x<width; ++_x ) {
            z = zi = 0.0;
            int steps = 0;
            for ( ; steps<ITERS; ++steps ) {
                double tmp = (z*z) - (zi*zi) + x;
                zi = 2*z*zi + y;
                z = tmp;

                if ( z*z + zi*zi > 4.0 ) break;
            }

            *ptr++ = f * steps2RGBA( steps<ITERS ? steps : 0 );

            x += sx;
        }

        y += sy;
        x  = block.x1;
    }
}

Что же дает "множитель яркости" f? Благодаря ему можно визуально разделять блоки, которые рассчитывались разными ядрами. Достаточно использовать при генерации значение, зависящее от номера текущего блока/ядра, например так: fractal_block( bounds, y, y+dy-1, (p+1)*6 );

При этом будет наблюдаться картина вроде такой:

Хорошо заметны 5 блоков, из которых состыкована текстура.

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

Реализация выполнена с подстройкой предела сходимости с целью снять ненужную нагрузку (на общем плане что 50 итераций, что 100 - визуально не заметно, а нагрузка ощущается). Соотвественно идет подстройка предела при масштабировании (также ее можно менять кнопками Up/Down).

Непосредственно по распараллеливанию. На машине с Core i5 750 в 2 потока отрисовка дает честный двухкратный прирост, на 4х потоках прирост порядка 3.5 раз. На приближении 2^40 и пределе итераций в 250 время работы 4х ядер 1.01сек против 3.64сек на одном. Была бы машина с иксами с большим числом ядер - было бы конечно интересней. Не раз встречал мнение, что распараллеливание особо проявляется не менее, чем на 8ми ядрах. Если у кого есть возможность и желание - запустите, интересен коэффициент прироста скорости в сравнении с одним и двумя ядрами.

Приближение 2^40 выбрано с целью предотвращения величин ошибок округления, влияющих на результат. Примерно на 42-43 итерации приближения размер окна в комплексной плоскости становится менее 6.82e-13 и начинают проявляться ошибки округления (underflow):

В итоге получаем достаточно неплохой результат ценой практически одной только строчки pragma

На очереди ArBB, TBB и что еще подвернется.

И еще немного картинок:

Исходники (tar.gz)

И всех с Наступающим!

Процесс декодирования восстанавливает последовательность в том же порядке в каком она кодировалась. Определим множество нормализованных кодов (нормализация на целый интервал):

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

Если до этого момента понятно так и не стало, то нас спасет только пример.

Следуя примеру из предыдущей заметки, входная последовательность символов: a2a1a0a0a1a3. Распределение вероятностей: p = [0.2, 0.5, 0.2, 0.1]. Код: 0.74267578125.

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

Как-то все непосредственно само сжатие, да итоговое досжатие тем же арифметическим кодером.

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

Что лучше сожмет ЭК? Конечно можно подать на вход 100500 нулей, но с такой вырожденной задачей отлично справится RLE. Тут важна предсказуемость и монотонность данных в потоке: было бы хорошо, если бы одинаковые значения (байт, бит) шли последовательно.

Можно рассматривать два наиболее популярных алгоритма: BWT и MTF.

В этот раз напишу про второй, т.к. первый (Burrows–Wheeler transform, преобразование Барроуза-Уиллера) прекрасно описан на Википедии, и смысла рассказывать тоже самое своими словами мало. Но если только кому-то будет интересно...

Итак, MTF (Move-To-Front, Движение к началу, Стопка книг, Сортировка стопки книг) является обратимым преобразованием над сжимаемым потоком, выполняемым с целью улучшения результатов последующего ЭК.

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

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

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

Для примера возьмем блок "20112012" и словарь из цифр "0".."9". Если сразу сжимать RLE, то будет найдено только "11" и ничего хорошего не выйдет. Если сжимать, Хаффманом или PPM с окном на все 8 байт, то будет найдено слово "201", что уже хорошо.

А теперь попробуем сначала преобразовать по MTF:

И по шагам:

0. Во входном буфере смотрим на первый символ, результирующий список позиций пуст, словарь с исходном виде;
1. Текущий символ "2" имеет позицию 2 в словаре. Добавляем 2 в результат, а "2" в словаре переносим в начало, получая "20134...";
2. Следущий символ "0" имеет позицию 1 в текущем словаре. Добавляем 1 в результат, а "0" в словаре переносим в начало, получая "02134..."
3. Аналогично повторяем для всего блока;
4. В результате получаем последовательность позиций символов в меняющемся словаре.

В итоге получаем последовательность "21202222". Которая в некоторых случаях будет сжата компактнее исходного варианта

Однако толку мало, если обратно раскодировать нельзя. А делается это просто: выполняем все в обратную сторону (но с исходным словарем):

И по шагам:

0. Во входном буфере смотрим на первый символ (позицию в словаре), результирующий список позиций пуст, словарь с исходном виде;
1. Текущий символ 2, а по позиции 2 в словаре символ "2". Добавляем "2" в результат, а "2" в словаре переносим в начало, получая "20134...";
2. Следущий символ 1, с этой позицией у нас символ "0". Добавляем "0" в результат, а "0" в словаре переносим в начало, получая "02134..."
3. Аналогично повторяем для всего блока;
4. В результате получаем исходную строку байт "20112012".

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

Пример реализации на Python:

#!/usr/bin/env python
#-*- coding: utf8 -*-

# создаем исходный словарь
DICT = [chr(i) for i in range(ord('0'),ord('9')+1)]

src = '20112012'

def encode(s,d):
    seq = []
    for c in s:
        i = d.index(c)
        seq.append(i)
        d.pop(i)
        d.insert(0,c)
    return seq

def decode(seq,d):
    s = []
    for i in seq:
        c = d[i]
        s.append(c)
        d.pop(i)
        d.insert(0,c)
    return ''.join(s)

print 'SOURCE:  ', src

enc=encode( src, DICT[:] )  # передаем копию словаря
print 'ENCODED: ', enc

dec=decode(enc,DICT[:])  # передаем копию словаря
print 'DECODED: ', dec

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

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

Само собой, если нет требования к сохранению исходных данных.

Каюсь, я и сам постепенно переключился с квестов на шутеры, а в последнее время прохожу от и до только сериалы FarCry/Crysis и GTA. «Раньше у нас было время, теперь у нас есть дела», как пел классик. Ну и жизнь порой подкидывала такие квесты, что компьютерные аналоги как-то перестали цеплять. Последним прошел, кажется, «Грим Фанданго» - и все, отрезало.

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

Но в Rockstar Games решили немного воскресить старый жанр. Еще в далеком 2004-м году они поддержали материально австралийскую компанию Team Bondi и приступили к совместной разработке полицейского триллера о Лос-Анджелесе конца сороковых. Чтобы с беготней по улицам, ездой на машинах, стрельбой – но и реальным участием геймера в расследовании преступлений. Для этого на лицах персонажей появилась почти естественная мимика, по которой можно определить – врет ли он, нервничает или, наоборот, рубит правду-матку от души. Планировалось, что игра выйдет в 2008 году, но тут некстати подкрался мировой финансовый кризис, и L.A. Noire отложили до лучших времен. Которые наступили только в мае сего года для приставочников и в ноябре для нас, обладателей настоящих компьютеров. Выход Windows-версии пришелся на не самый лучший период в жизни Team Bondi: в октябре компания обанкротилась, оставив кредиторам разного рода расписок на миллион с лишним долларов США. К счастью, повлиять это может разве что на выход сиквела, если таковой вдруг случится, а оригинальная игра к тому моменту была закончена полностью.

Итак, что такое L.A. Noire?

Во-первых, это GTA IV с сильно улучшенной графикой, действие которой происходит на улицах Лос-Анджелеса образца 1947 года. Ездят машины, ходят люди, дома и улицы очень похожи на настоящие – в общем, залюбуешься. Вот только машины угонять теперь не надо, у полицейского всегда есть своя. И давить людей не рекомендуется, за это жестоко штрафуют и заставляют переигрывать эпизоды. Стрелять можно, но только в конченных негодяев, а так – только в воздух.

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

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

Преступления в L.A. Noire приходится расследовать самые разные – от угона автомобиля у аргентинского посла, оказавшегося… не очень хорошим человеком, до негодяйств серийного убийцы. Приятно, что тебе не дают притомиться от однообразия. Едешь с локации на локацию, а тут тебе подбрасывают какую-то мелочевку, вроде кражи в магазине. Несешься, разбираешься, а потом уже снова занимаешься серьезным делом.

Системные требования у игры приемлемые. На Radeon 6850 она неплохо работает при разрешении 1600х1200 при почти максимальных графических настройках, и только со сглаживанием лучше не перебарщивать. На опробованной недавно GeForce 560Ti (ультратихой, производства Palit) все совсем хорошо. И теперь главное, ради чего, собственно, этот пост и написан С поддержкой многоядерности у L.A.Noire порядок: два ядра процессора нагружены постоянно, а остальные – в зависимости от сложности сцены. Конечно, хотелось бы перетащить на CPU еще больше, чтобы GPU грелся поменьше, но это, пожалуй, уже из области капризов.

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

На сим закругляюсь. Надо уже наказать этого неуловимого маньяка…

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

Теоретическое введение

Введение

Для начала, необходимо определить, что такое нейрон. В
биологии нейрон - специализированная клетка, из которой состоит нервная система. Биологический нейрон имеет строение, показанное на рис.1.

Рис.1 Схема нейрона

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

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

В качестве архитектуры нейронной сети будет использоваться сеть Хопфилда. Данная модель, видимо, является наиболее распространенной математической моделью в нейронауке. Это обусловлено ее простотой и наглядность. Сеть Хопфилда показывает, каким образом может быть организована память в сети из элементов, которые не являются очень надежными. Экспериментальные данные показывают, что при увеличении количества вышедших из строя нейронов до 50%, вероятность правильного ответа крайне близка к 100%. Даже поверхностное сопоставление нейронной сети (например, мозга) и Фон-Неймановской ЭВМ показывает, насколько сильно различаются эти объекты: к примеру, частота изменения состояний нейронов ("тактовая частота") не превышает 200Гц, тогда как частота изменения состояния элементов современного процессора может достигать нескольких ГГц (10⁹Гц).

Формальное описание сети Хопфилда

Сеть состоит из N искусственных нейронов, аксон каждого нейрона связан с дендритами остальных нейронов, образуя обратную связь. Архитектура сети изображена на рис. 2.

Рис.2 Архитектура нейронной сети Хопфилда

Каждый нейрон может находиться в одном из 2-х состояний:

(1)

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

Динамика состояния во времени -ого нейрона в сети из нейронов описывается дискретной динамической системой:

(2)

где - матрица весовых коэффициентов, описывающих взаимодействие дендритов -ого нейрона с аксонами -ого нейрона.

Стоит отметить, что и случай не рассматривается.

Обучение и устойчивость к шуму

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

Важной характеристикой нейронной сети является отношение числа ключевых образов , которые могут быть запомнены, к числу нейронов сети : . Для сети Хопфилда значение не больше 0.14.

Вычисление квадратной матрицы размера для ключевых образов производится по правилу Хебба:

(3)

где означает -ый элемент образа

Стоит отметить, что в силу коммутативности операции умножения, соблюдается равенство

(4)

Входной образ, который предъявляется для распознавания соответствует начальным данным для системы, служащий начальным условием для динамической системы (2):

(5)

Уравнений (1), (2), (3), (5) достаточно для определения искусственной нейронной сети Хопфилда и можно перейти к ее реализации.

Реализация нейронной сети Хопфилда

Реализация нейронной сети Хопфилда, определенной выше будет производиться на языке C++. Для начала, необходимо определить дополнительные типы данных (подробнее см. листинг 1)

• тип весовых коэффициентов (выбран тип float);
• тип, описывающий состояние нейрона (выбран собственный введеный тип-перечисление);
• тип, описывающий состояние сети в момент t (выбран стандартный контейнер vector);
• тип, описывающий матрицу весовых коэффициентов связей нейронов (выбран контейнер vector контейнеров vector).

Листинг 1. Определение новых типов

enum neuron_state {LOWER_STATE=-1, UPPER_STATE=1};
typedef float koef_t;
typedef vector<neuron_state> neurons_line;
typedef vector<vector<koef_t>> link_koefs;

Обучение сети, или, точнее, вычисление элементов матрицы в соответствии с (3) производится функцией LearnNeuroNet, принимающей на вход список обучающих образов и возвращающей объект типа link_koefs_t. Значения вычисляются только для нижнетреугольный элементов. Значения верхнетреугольных элементов вычисляются в соответствии с выражением (4). Общий вид метода LearnNeuroNet показан в листинге 2.

Листинг 2. Обучение нейронной сети

link_koefs LearnNeuroNet(const list &src_images) {
	link_koefs result_koefs;
	size_t neurons_count = src_images.front().size();

	result_koefs.resize(neurons_count);
	for (size_t i = 0; i < neurons_count; ++i) {
		result_koefs[i].resize(neurons_count, 0);
	}

	for (size_t i = 0; i < neurons_count; ++i) {
		for (size_t j = 0; j < i ; ++j ) {
			koef_t val = 0;
			val = std::accumulate(begin(src_images), end(src_images), koef_t(0.0), [i, j] (koef_t old_val, const neurons_line &image) -> koef_t{
				return old_val + (image[i] * image[j]);
			});
			result_koefs[i][j] = val;
			result_koefs[j][i] = val;
		}
	}

	return result_koefs;
}

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

Оператор функтора модифицирует передаваемый объект типа neurons_line до состояния нейронной сети в момент времени . Значение жестко не фиксировано и определяется выражением:

(6)

т.е., когда состояние каждого нейрона не изменилось за 1 "такт".

Для вычисления (2) применены 2 алгоритма STL:

• inner_product для вычисления суммы произведений весовых коэффициентов и состояний нейронов (т.е. вычисление (2) для определенного );
• transform для вычисления новых значений для каждого нейрона (т.е. вычисление пункта выше для каждого возможного )

Исходный код функтора neurons_net показан в листинге 3.

Листинг 3. Функтор, реализующий работу нейронной сети

struct neuro_net_system {
	const link_koefs &_koefs;
	size_t _steps_processed;

	neuro_net_system(const link_koefs &koefs): _koefs(koefs) {}

	bool Execute(neurons_line *line) {
		bool value_changed = false;

		neurons_line old_values(begin(*line), end(*line));
		link_koefs::const_iterator it_koefs = begin(_koefs);

		std::transform(
			begin(*line),
			end(*line),
			begin(*line),
			[&old_values, &it_koefs, &value_changed] (neuron_state old_value) -> neuron_state {
				koef_t tmp_val = std::inner_product(
					begin(old_values),
					end(old_values),
					begin(*it_koefs++),
					koef_t(0)
				);
				neuron_state new_value = (tmp_val > 0 ? UPPER_STATE : LOWER_STATE);
				value_changed = (new_value != old_value) || value_changed;

				return new_value;
		});

		return value_changed;
	}

	neurons_line* operator () (neurons_line *line) {
		bool need_continue = true;
		_steps_processed = 0;

		while (need_continue) {
			need_continue = Execute(line);
			++_steps_processed;
		}

		return line;
	}
};

Для вывода в консоль входных и выходных образов создан тип neurons_line_print_descriptor, который хранит ссылку на образ и формат форматирования (ширину и высоту прямоугольника, в который будет вписан образ). Для этого типа переопределен оператор <<. Исходный код типа neurons_line_print_descriptor и оператора вывода в поток показан в листинге 4.

Листинг 4. Обучение нейронной сети

struct neurons_line_print_descriptor {
	const neurons_line &_line;
	const size_t _width;
	const size_t _height;

	neurons_line_print_descriptor (const neurons_line &line, size_t width, size_t height): _line(line), _width(width), _height(height) {}
};

template <typename Ch, typename Tr>
std::basic_ostream<Ch, Tr>& operator << (std::basic_ostream<Ch, Tr>&stm, const neurons_line_print_descriptor &line) {
	neurons_line::const_iterator it = begin(line._line), it_end = end(line._line);

	for (size_t i = 0; i < line._height; ++i) {
		for (size_t j = 0; j  0)
				cout << " ";
			else
				cout << "0";
			++it;
		}
		cout << endl;
	}

	return stm;
}

Рабочий пример можно скачать отсюда.
Пример представляет собой проект MS VisualStudio 2010. Пример компилируется компиляторами VC++ и Intel C++ (другие компиляторы не проверялись).

Пример работы нейронной сети

Для проверки работоспособности реализации, нейронная сеть была обучена 2 ключевым образам:

Рис.3 Ключевые образы

На вход подавались искаженные образы. Нейронная сеть корректно распознала исходные образы. Искаженные образы и распознанные образы показаны на рис.4, 5

Рис.4 Распознавание образа 1

Рис.5 Распознавание образа 2

Запуск программы производится из командной строки строчкой вида: AppName WIDTH HEIGHT SOURCE_FILE [LEARNE_FILE_N], где:

Использованная литература

1. Г.Г. Малинецкий. Математические основы синергетики. Москва, URSS, 2009.
2. Статья "Нейронная_сеть_Хопфилда" на Википедии.

1988 год – H.261

Итак, 1988 год. H.261 стал первым полноценным форматом видеосжатия, получившим широкое распространение. Это был «классический» стандарт, работающий в цветовом пространстве YCbCr, базирующийся на дискретном косинусном преобразовании блоков и сжатии Хаффмана. Поднимите руку те, кто слышал о нём? А ведь именно в этом стандарте впервые появились такие понятия, как макро-блок, целопиксельный вектор движения и де-блокинг (или пост-процессинг). А еще именно тогда, 23 года назад, появилась концепция опорных кадров. H.261 предусматривал кадры 2х типов: I(ntra) – полностью независмый кадр, и P(redicted) – кадр, зависимый от предыдущего. Максимальное разрешение CIF (пример приведён слева), поддерживаемое H.261, сейчас не впечатлит даже любителей смотреть видео на телефоне. И тем не менее, для своего времени это был очень прогрессивный, весьма «продвинутый» стандарт. Все последующие стандарты видеосжатия базируются на идеях, берущих свое начало в H.261, и де-факто являются результатом его эволюционного развития.

1993 год – MPEG1

В 1993 появился MPEG1. Революционным нововведением в формате MPEG1 стали B(ipredicted) кадры. Т.е. кадры могли теперь предсказываться не только от предшествующего опорного кадра, но и последующего. Появились полупиксельные вектора движения, что позволило поднять точность предсказания и тем самым повысить качество. Было введено понятие «слайс» (Slice) – часть кадра (группа макроблоков), которая кодируется независимо от других слайсов. Стало возможным сжимать разные части кадра с разными параметрами, но, самое главное, в MPEG1 появилась поддержка очень больших разрешений, вплоть до 4К на 4К.
По непонятной причине, комитет MPEG выкинул из стандарта этап де-блокинга. Комитет даже не убедило существенное повышение качества, достигнутое при использовании де-блокинга в стандарте H.261. Скорее всего, решение было основано на данных о типичной производительности микропроцессоров того времени. В отличие от H.261, стандарт MPEG1 состоял из нескольких частей, описывающих всё необходимое для полноценного цифрового видео: аудио сжатие, видео сжатие, хранение и синхронизация аудио-видео данных, средства тестирования совместимости и референсный декодер для отладки.

В начале девяностых годов в компании Intel, да и вообще в компьютерной индустрии, вряд ли существовало полное понимание того, какое влияние в будущем окажет видеокодирование на архитектуру процессоров. Это много позже сжатие и разжатие цифрового видео стало коньком компании. А пока, в марте 1993, начал свою долгую жизнь один из самых известных процессоров компании Intel – Pentium. В нем не было ничего особенного для ускорения видео-обработки, разве что одинокая инструкция bsr (bit scan reverse). Эта инструкция осталась еще со времён 386го процессора и могла быть использована для ускорения декодирования Хаффмана. Производительности Pentium’а хватало, чтобы тихонько декодировать H261 формат. Но без звука . Надеюсь, некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой.

1996 год – MPEG2

1996 год. Опубликован стандарт MPEG2. Совсем скоро разойдутся по планете миллионными тиражами DVD диски, которые сделают MPEG2 первым широко распространенным форматом на многие годы. MPEG2 практически не принёс ничего нового в процесс сжатия, за исключением черезстрочного видео, поддержки нескольких форматов аудио-сжатия и дополнительных цветовых разрешений. MPEG2 не был оптимизирован для использования на маленьких (меньше 1мбит) потоках. Зато на бОльших потоках MPEG2 уверенно превосходил MPEG1, а сам стандарт разросся до 11 частей.

В начале 1997 года Intel начала продавать процессоры, которые уже были способны декодировать видео с приемлемой скорость. Нет, про HDTV разрешения ещё никто не мечтал, но маленькое QCIF видео процессор уже способен был проигрывать без тормозов. «Виновница» этого – технология MMX. Врядли выход стандарта MPEG2 и технологии MMX с такой маленькой разницей во времени было чистым совпадением. С большой вероятность это был, как сейчас принято говорить, продукт синэргии.

Технология MMX состояла из набора дополнительных 57 инструкций и 8 новых 8ми-байтных регистров. Существенное ускорение (до 3х-4х раз) достигалось за счёт одновременной обработки инструкцией нескольких данных. В этом плане цифровое видео стало идеальным полем для внедрения новой технологии. На MMX возлагали большие надежды, и даже поместили на официальное лого процессора.
Чуть позже в этом же году вышел процессор Pentium II, который за счёт своей суперскалярности, большого кэша, шустрой шины и нового типа памяти сделал доступным просмотр DVD на персональном компьютере.

1998 год – MPEG4

MPEG4, появившийся в 1998 году, достаточно быстро завоевал себе славу «пиратского» формата. Кодек DivX, использующий MPEG4 формат, произвёл настоящий фурор. DivX позволял с приемлемой потерей качества сжимать MPEG2 DVD диск в файл размером с CD диск. Я помню, как многие мои друзья кинулись пережимать DVD фильмы (откуда они их брали???) и делать свою личную коллекцию DivX фильмов.
Успех формата MPEG4 состоял из нескольких слагаемых: вектора движения стали четверть-пиксельными, что позволило поднять точность предсказания, макроблок мог содержать уже до 4 векторов движения, что было полезно на границе движущихся объектов, и (фанфары!) вернулся незаслуженно уволенный пять лет назад де-блокинг.
Разработчики стандарта добавили в MPEG4 ещё одну интересную вещь: intra-предсказание. Теперь макроблоки в I-кадрах могли «предсказываться» от соседних макроблоков, что существенно снижало размер intra макроблоков в кадрах со сложной, но повторяющейся структурой.
К сожалению, сам стандарт сжатия, а вернее его чрезмерные способности, не нашли горячего отклика в лице производителей кодеков. Многие прогрессивные фишки MPEG4, такие как 3D видео текстуры, несколько видеоплоскостей в кадре и прочее, остались невостребованными.

С другой стороны, многократно возросшая сложность декодирования опять отбросила пользователей в область маленьких разрешений. Однако, не прошло и года, как в продаже появился Pentium III, «ускоряющий Интернет». К слову, Pentium III отлично справлялся с задачами ускорения всего, не только интернета. В то время были популярными эксперименты запуска игры Quake 3 Arena на новом процессоре, который после патча системы обеспечивал значительное приращение FPS. С точки зрения видеокодирования, процессор принёс возможности программного опережающего чтения (prefetch) данных в кэш и расширял набор MMX несколькими крайне полезными инструкциями. И хотя ускорение декодирования видео было всего 20-30% по сравнению с Pentium II, этого было достаточно для комфортного просмотра MPEG4 фильмов.

Приверженцы продукции Intel встречали 2000й год с особыми нетерпением. Именно на этот год был назначен выпуск нового процессора Intel Pentium 4. Это была великая интрига и великая загадка – компания готовилась полностью сменить архитектуру процессора. Архитектура NetBurst шла на смену казавшейся устаревшей архитектуры P6. И хотя общая производительность процессора слегка разочаровала фанатов, с точки зрения обработки цифрового видео процессор был на высоте. Новые инструкции и новые 16ти-байтные регистры SSE2, хитрые режимы аппаратного предсказания, большие буффера чтения/записи, новая организация кэша, а чуть позже – технология HyperThreading. Всё это вдохнуло новую жизнь в процесс оптимизации видеокодеков. Прирост производительности колебался от 10 до 35%. Процессор Pentium 4 был раздольем для экспериментов. Например, 2 инструкции, переставленные местами, могли равновероятно принести как 5% увеличения скорости работы кодека, так и 5% замедления. Процессора вполне хватало на декодирование и видео, и аудио, и еще оставалось немножко производительности на спец-эффекты. Вкладка эффектов DivX росла и ширилась, и счастливые обладатели топовых версий Pentium 4 расставляли все галочки, в надежде получить картинку «как в кинотеатре». А раз уж речь зашла о кинотеатре, то энтузиасты начали всерьез посматривать в сторону HD разрешений.

Новейшая история, год 2003 – H.264

Год 2003 можно смело назвать эпохальным годом в истории развития форматов видеосжатия: появилась альфа и омега сегодняшнего цифрового видео — стандарт H.264. Новый стандарт был полностью целочисленным, т.е. все этапы декодирования видео выполнялись в целых числах, благодаря чему была достигнута побитовая идентичность видео при декодировании декодерами разных производителей.
От предков H.264й отличался продвинутым intra-предсказанием макроблоков, различным разбиением макроблоков при компенсации движения (от 4x4 до 16x16), 6ти точечным фильтром компенсации движения, продвинутым арифметическим сжатием энтропии, наличием долго-хранящихся опорных кадров, гибким управлением опорными кадрами, 16 векторами на макроблок, всеми доступными цветовыми разрешениями, 8мью и более битами на компонент цвета и множеством других волшебных фишек. Стандарт не только оставил далеко позади всех конкурентов, но и установил новые требования к производительности процессора. Теперь, чтобы проигрывать видео в формате HD, одного процессора (даже с технологией HyperThreading) уже недостаточно.

Период 2003-2005 годов был тяжёлым для пользователей, которым не хватало производительности, но золотым временем для оптимизаторов ПО. Их услуги были на расхват! Производительность ЦПУ явно была в дефиците, и с этим надо было что-то делать. В мае 2005 решение пришло – впервые со времён процессора Pentium III многоядерность вернулась в пользовательские машины. Процессор Pentium 4 с кодовым названием Smithfield гордо нёс свои 2 ядра в массы. На самом деле, компания Intel слукавила – это были 2 «почти» обычных процессора Pentium 4, расположенные на одной подложке. Процессоры могли общаться друг с другом исключительно через шину FSB, не могли «подглядывать» соседу в кэш. Тем не менее, производительности Smithfield’а было достаточно, чтобы на лицах пользователей снова засветилась улыбка. Покупайте попкорн, занимайте места в «зрительном» зале. Только благодаря многоядерности в многолетней битве между процессорами и форматами цифрового видео наметился перелом: процессоры стали способны декодировать цифровое видео в любом формате, в любом разрешении с комфортной для зрителя скоростью. Но это был лишь выигранный бой, но не сражение.
Как мы знаем, цифровое видео можно (и нужно) не только ДЕкодировать, но и в первую очередь кодировать. А вот с этим всё было не так радужно, как того бы хотелось. Для полноценного, быстрого и качественного сжатия видео современных процессоров хватало разве что на стандартное разрешение формата MPEG2/MPEG4, не более.

Городок Конро на юго-востоке штата Техас был практически неизвестен до лета 2006 года, когда на прилавках магазинов стали поставляться новые процессоры компании Intel с одноимённым ядром, вернее ядрами. Дальний потомок процессора Pentium III Intel Core 2 был призван заменить процессоры на базе технологии NetBurst, и закрепить успехи видео(де)кодирования. Процессор обладал полноценными высокопроизводительными ядрами, которые могли достаточно эффективно лазить друг другу в большой кэш, и новыми инструкциями SSSE3 (3 буквы S). Среди новых инструкций было несколько ориентированных специально на кодирование видео. И хотя новые процессоры потеряли поддержку HyperThreading, они всё равно обладали такой внушительной производительностью, что сжатие HD видео в реальном времени уже не выглядело совсем непосильной задачей.

Однако, как уже было замечено, появление многоядерности принесло победу в бою, но не в сражении. Осенью 2007 года объединённая группа комитетов наносит ответный удар в виде нового профиля масштабируемого сжатия к стандарту H264 Scalable Video Coding (SVC). Сложность кодирования и декодирования возрастает в разы. Это был не полноценный стандарт, а всего лишь настройка над существующим, основная задумка которого – существенное повышение качества видео, передаваемого по сетям с потерями. Теперь в видео потоке один и тот же фильм мог храниться в разных разрешениях, и более высокие разрешения использовали более низкие в качестве опорных. У такого решения был ещё один дополнительный плюс: теперь устройства, которые не нуждалось в HD качестве фильма, могли декодировать только часть потока с необходимым разрешением.

Но ничто уже не могло поменять ситуацию в обратную сторону. Компания Intel в начале 2008 закрепляет свой успех выходом процессора на ядре Penryn с новыми инструкциями SSE4.1. Как скажут позже – это было самое большое SIMD расширение со времён процессора Pentium III. Тут были и абсолютно новые инструкции, заточенные на кодирование цифрового видео, и новые расширения для уже существующих SIMD инструкций. Кодирование HD видео в формате H264 уже уверенно движется в реальном времени с приемлемым качеством.
Вышедший в ноябре 2009 новый профиль для кодирования видео снятого с нескольких точек для формата H264 Miltiview video coding (MVC) не мог ничего изменить. Новый профиль не добавлял ничего нового, просто описывал правила и способы организации битового потока для сжатия видео снятого с нескольких камер. Не смотря на то, что производительности процессоров 2009 года не хватало, чтобы сжимать подобное видео в реальном времени, это был вопрос одного, максимум двух поколений процессоров.

Так и произошло. На рынок вышел процессор с кодовым именем Nehalem, снова подаривший нам радость использования технологии HyperThreading. Среди прочих достоинств процессор нёс на себе контроллер памяти и кольцевую шину, которая более подходила для связи между большим количеством быстрых ядер, чем морально-устаревшая FSB. Процесс сжатия HD фильма в отличном качестве, который раньше занимал всю ночь, теперь пролетает за «считанные» часы. В воздухе витал дух победы. Однако, компания Intel была бы не компания Intel, если бы не поставила красивый заключительный аккорд в этой борьбе.

И он прозвучал: в январе 2011 было объявлено о начале продаж процессора на ядре SandyBridge. Кто вертел фирменную синюю коробочку упаковки процессора, наверняка заметили слова Intel Quick Sync среди списка features процессора. Именно так называется технология аппаратного сжатия видео, которая доступна каждому пользователю через Intel media SDK. За этими тремя простыми английскими словами скрывается труд десятков инженеров и программистов компании, в том числе и мой.

В 2002 году я разговаривал с одним своим коллегой насчёт оптимизации и мультимедиа-ориентированности современных процессоров (как вы помните, время господства технологии SSE2). И на какой-то мой довод коллега ответил, что процессоры станут мультимедиа-ориентированными только тогда, когда там появится инструкция idct. Могли ли мы предположить в далёком 2002, что спустя всего 9 лет жизнь оправдает гораздо более смелые планы и ожидания?

Теперь сжатие видео для любимого iPad – не проблема. HD сериал из 24 серий по 20 минут кодируется за 20 минут. Фильм на 1.5 часа кодируется за 5 минут. Больше не надо тратить своё время и оставлять компьютер включенным на ночь. Достаточно просто сходить и налить чай. Процессоры победили.

PS: На этом я хотел бы закончить своё повествование, но это было бы лукавством. В воздухе опять пахнет бурей. Дело в том, что объединенная группа комитетов разрабатывает следующий стандарт сжатия цифрового видео – High Efficiency Video Coding (HEVC). HEVC будет нести в себе лучшие качества H264 формата, но при этом будет обладать огромным количеством новых особенностей и возможностей, которые предъявят повышенные требования к ЦПУ. И борьба между стандартами видеосжатия и процессорами может выйти на новый виток. И так до бесконечности.

Upd. Я уверен, что со временем программные средства развивались, и некоторые негативные эффекты, описанные в статье, со временем прошли. Например, winamp перестал «икать» на медленных процессорах.

Кроме шуток, о самой технологии я, конечно, знал давно. Но все как-то не складывалось познакомиться. Весь компьютерный парк в домохозяйстве казался довольно современным, и ни один Sandy Bridge в него прорваться не мог. И только сейчас, когда у меня на тесте оказался ультрабук Acer Aspire S3, наконец-то собрался проверить Quick Sync в действии. И то, каюсь, после напоминания Дмитрия Оганезова. Конечно, если бы раньше знал, насколько это классно, я бы и тесты провел давно, и апгрейдом озаботился. Но задним умом мы все крепки, да.

Вот как все было. Сначала поставил на ультрабук программу ArcSoft MediaConverter 7, поддерживающую Intel Quick Sync. Для тестов взял два видеофайла. Первый – довольно большой рип фильма Across The Universe (его обязательно должны посмотреть все поклонники The Beatles) с шириной кадра 1024 точки и продолжительностью 2 часа 13 минут. Второй файл попроще, DVD-рип отечественного фильма «М+Ж» (не могу посмотреть уже больше двух лет, но регулярно использую для опытов), который идет 1 час 16 минут.

В MediaConverter’е выбрал кодирование для PSP. Запустил по очереди оба файла.

Across The Universe перекодировался за 20 минут 7 секунд
«М+Ж» за 10 минут 11 секунд

Пока не буду ничего комментировать, давайте просто запомним эти цифры.

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

На выходе получил 27 минут 24 секунды и 14 минут 42 секунды соответственно.

А вот теперь уже точно можно начинать восхищаться.

В ультрабуке трудится скромный ULV-процессор Intel Core i5-2467M с рабочей частотой 1.6 ГГц. У него два ядра с поддержкой HT, и под нагрузкой он может разогнаться до 2.1 ГГц, или даже до 2.3, если нагружается только одно ядро. Но это настоящий Sandy Bridge со всеми вытекающими. TDP его составляет 17W.

В моем домашнем компьютере установлен четырехъядерный Core i7-965 Extreme Edition с рабочей частотой 3.2 ГГц. Под нагрузкой – 3.46 ГГц. TDP 130W.

Так вот этого МОНСТРА ULV-процессор с Quick Sync сделал одной левой. И, знаете ли, во время кодирования еще умудрялся периодически сбрасывать частоту до 800 МГц!!! Как бы намекая, что ему совсем не тяжело.

Даже не знаю – что тут скажешь? Восторг! Экстаз! Торжество технологий в чистом виде!

Я бы, наверное, даже не смог от удивления написать этот пост, но мои чувства чуть охладил проверенный конвертер Xvid4PSP. Оказалось, что ArcSoft MediaConverter 7 как-то не очень эффективно использует старый Core i7, а вот Xvid4PSP умеет нагружать его полностью.

Результаты оказались такие:

Across The Universe: 24 минуты 23 секунды
«М+Ж»: 12 минут 18 секунд секунд

Отрыв вроде бы сократился. Но не забываем, что ядер В ДВА раза меньше, а частота их тоже ВДВОЕ ниже. То есть налицо, как минимум, четырехкратное превосходство ультрамобильного современного процессора над монстром прошлого поколения. А уж десктопные ребята уделали бы моего старичка еще более сурово.

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

На очередной виртуальной сессии Игорь Воробцов расскажет об Intel® VTune™ Amplifier XE 2011. Этот инструмент входит в состав пакета Intel® Parallel Studio XE 2011 и является новейшим профилировщиком производительности. Вы узнаете как о новых возможностях инструмента, так и о дополнительном функционале, специально предназначенном для разработчиков игр. Вы узнаете о такой интересной функциональной возможности, как анализ кадров для фильтрации результатов профилировки производительности с целью получения информации, на основании которой могут быть предприняты конкретные действия. Эта функция основана на потребностях видеоприложений (таких как игры) и должна соответствовать критериям задержки для каждого видеокадра. Она реализована с использованием общей методики и может быть полезна и в других приложениях, например, в симуляторах циклов.

Регистрируйтесь на сайте intelcorp.regsvc.com/E6129, чтобы изучить основные возможности и функциональность инструмента.

Если вы не смогли посетить 1-ый вебинар серии, видео-запись можно посмотреть и скачать в нашем Take 5 видео-репозитории.

Еще до покупки игры мне приходилось слышать, что с ней не все в порядке: мол, глючит страшно, и в id Software объясняют проблемы очень просто – мол, компания не рассматривает PC, как основную платформу для игр. И все же я был уверен, что трудности преувеличены: ну может где-нибудь текстурка мигнет, или игра зависнет пару раз за день… В конце концов, это же id Software, «премиальный бренд», не может же она выпустить на рынок совсем недоделанный продукт?

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

Расскажу о своих мытарствах подробнее. Игра поставляется аж на 3 DVD и занимает на жестком диске больше 15 гигабайт. При первом запуске она порадовала меня дикой мешаниной из текстур, исключающей возможность собственно играть. Несколько озадаченный, я стал советоваться с Интернетом, вывалившим на меня целую груду рецептов. Перво-наперво порекомендовали установить новую бета-версию драйвера для моего Radeon HD6850. Я скачал сначала неправильную, выпущенную 8 октября, и она решала проблему капитально: просто отключала ВСЕ текстуры и всё. Картинка выглядела чуть лучше, чем в легендарном Wolfenstein 3D,но желания поиграть почему-то не вызывала. Добрые люди прислали ссылку на правильную бету, которая Preview 3. При ее установке компьютер впервые за очень долгое время продемонстрировал синий экран, но после аварийной перезагрузки Rage запустилась с текстурами. Счастье, правда, длилось недолго: продемонстрировав свою красоту, игра начала зависать. Делала она это настолько регулярно и разнообразно, что невольно вспомнился перечень способов приготовления креветок из фильма «Форрест Гамп». Она зависала при загрузке уровня, при попытке выйти в главное меню, при переключении задач, при оглашении сути очередного задания, при сохранении игры, при подгрузке текстур… Наконец, больше всего ей нравилось зависать просто так. А бета-драйвер оказался настолько совершенным, что намертво вешал Adobe Photoshop, пока я не догадался отключить в нем поддержку вычислений на GPU.

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

И вот это – id Software. Легенда, технологический лидер и просто небедный коллектив разработчиков, уж точно способный позволить себе целую банду QA-специалистов. Провал же получился такой, что я даже не могу припомнить аналогов. Да, бывало, новые игры неприлично тормозили и вылетали, но чтобы вообще толком не работали… Нет, не могу вспомнить.

И главное – не получается объяснить причину случившегося. Кроме, разве что, взбешенных пинками менеджеров разработчиков PC-версии, которые из вредности отправили на золото заведомо сырую бета-версию. Мол, не хотите подождать еще полгодика? Ну, вот вам. Продавайте, если сможете.

Что характерно, приставочные версии работают стабильно, но тут всплывает другой меганедостаток: Rage безнадежно однообразна и скучна. Как только надоедает смотреть по сторонам, любуясь действительно роскошными пейзажами, желание играть тут же пропадает. Сюжет никогда не был сильной стороной игр id Software, но тут на нем отдохнули как-то особенно хорошо.

В те короткие моменты, когда игра работала, я смог понаблюдать за нагрузкой на процессор и GPU. С удовлетворением отметил, что движок id Tech 5 эффективно использует четыре ядра процессора, распределяя между ними нагрузку практически поровну. Пиковая нагруженность графического чипа составила 69% (разрешение 1600х1200), но обычно она не превышает 62%. В результате компьютер не перегревается и не шумит.

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

P.S. Заголовок этого поста отсылает к популярному в свое время боевику "Слепая ярость" с Рутгером Хауэром в главной роли. Вот только не уверен, что нынешняя молодежь его вообще помнит

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

В эту пятницу Кирилл Рогожин расскажет о том, как эффективно использовать библиотеку Intel® Threading Building Blocks для распараллеливания кода. Эта библиотека призвана облегчить работу программистам и позволяет сфокусироваться на особенностях своего приложения, а не "изобретать велосипед". С TBB вы сможете сосредоточиться на основных функциях приложения, а не на организации и отладке многопоточной работы.

Через неделю, 21 октября, вас ждет виртуальная сессия, посвященная инструменту Intel® VTune™ Amplifier XE 2011, который является новейшим профилировщиком производительности. Игорь Воробцов представит новые возможности и функциональность VTune™ Amplifier, такие как временная линия потоков, статистическое дерево вызовов, мультиплексирование событий, а также ряд дополнительных функциональных возможностей, специально предназначенных для разработчиков игр, которым нужен более комплексный подход. Использование инструмента Intel® VTune™ Amplifier XE 2011 будет продемонстрировано на примере работы с игрой «Total War: Empire».

На двух последних вебинарах Виктория Жислина расскажет о том, как учитывать особенности CPU (устройство кэш-памяти, предсказание ветвлений, out-of-order исполнение, SIMD инструкции, включая Advanced Vector Extensions) для создания максимально оптимизированных приложений, а также о схеме построения игрового движка на основе задач (tasks).

Ознакомиться с расписанием и зарегистрироваться на вебинары можно на этой странице. Регистрация на последние два вебинара серии откроется в самое ближайшее время.

Регистрируйтесь, следите за обновлениями и приходите на наши виртуальные сесии. Увидимся в эту пятницу!