В качестве пиксельной матрицы возьмем массив 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)

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

В качестве альтернативы можно использовать целочисленные операции, основанные на работе не с одним значением внутри интервала, а с текущими границами. Если арифметический кодер работает в пределах интервала [0,1), то интервальный кодер начинает с интервала [0,N), где N - произвольный верхний предел, от которого и зависит максимальный размер обрабатываемого блока. Логично брать N, основываясь на аппаратных возможностях архитектуры, например 2^32.

Каждый обрабатываемый символ сужает интервал, приводя его в итоге к [x,x+1), что является предельным значением точности и размера обрабатываемого блока. Подинтервалы, в которые сужается исходный [0,1), как и в случае с арифметическим кодированием берутся исходя из вероятности появления данных символов во входном потоке. Учет вероятностей позволяет оптимально использовать выделенный интервал, предоставляя "чаще используемым" символам больший диапазон значений.

Эксперимента ради, попробуйте разделить интервал [0,20) на 10 частей, а потом на столько же частей интервал [0,5), сохраняя при этом целочисленную точность. И почувствуйте разницу

Рассмотрим пример сжатия строки "abraha#" (сократил "abrahadabra") с вероятностями:

Символ "#" является служебным терминальным и нужен на случай, если после сжатия в потоке вывода не передается исходная длина строки. В таком случае появление данного символа при декодировании будет служить сигналом завершения работы (аналогично EOF, EOL, etc).

В качестве максимального значения возьмем N=100.000.000 (100 миллионов).
Преобразуем вероятности появления символов в отрезки на интервале [0,N):

• a = 40% = 0.4 => 0.4*N - верхняя граница интервала
• b = 20% = 0.2 => 0.2+0.4 = 0.6*N - верхняя граница интервала, а нижняя - 0.4*N
• ...

Получаем:

[     0,  0.4*N)

[ 0.4*N,  0.6*N)

[ 0.6*N,  0.7*N)

[ 0.7*N, 0.95*N)

[0.95*N,      N)

Кодирование строки по шагам:

В результате имеем интервал [22,110,400 ... 22,112,000). Любое значение из этого интервала даст нам результат кодирования.
Для выбора оптимального значения можно выбрать то, в котором будем максимальное число нулевых младших бит среди всех возможных. Если имеем интервал [f,t), то искомой величиной будет:

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

Если брать просто среднее значение интервала, то в качестве ответа будет 22,111,200. Если взять оптимальное значение, то получим 22,111,232. Для сравнения, их бинарное представление:

22,111,200 = 1010100010110001111100000
22,111,232 = 1010100010110010000000000

Декодирование выполняется еще более похоже на арифметическое кодирование:

1. имея значение cur из текущего интервала [f,t), получаем соответствующий символ c;
2. нормализуем интервал до [0,N), получая новое значение new по формуле:
   
3. повторяем шаги 1 и 2 до встречи терминального символа, либо до достижения исходной длины строки (если известно).

Декодирование строки по шагам:

Ну и пример реализации на Python:

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

from math import floor, log, ceil

class Arithmetic:

    def __init__(self, freqs_tuples, MAX):
        # верхняя граница интервала
        self.max = MAX
        # подготовка словаря с интервалами вероятностей символов
        self.__freqs2dict( freqs_tuples )

    def encode(self, s):
        u"""
            Кодирование строки s на основе вероятностей в self.freqs
            Возвращает число из итогового диапазона
        """
        # начинает с полного интервала [0,1)
        (f, t) = (0, self.max)
        for c in s:
            # координаты нового интервала
            (cf, ct) = self.freqs[c]
            # длина базового интервала
            t_f = t-f
            # Получение нового интервала.
            # Важно: т.к. в вычислении фигурирует f, то его
            # изменение выполняется только после вычисления t.
            # Т.е. не надо менять строки местами : )
            t = int( floor( ct*t_f / self.max + f ) )
            f = int( floor( cf*t_f / self.max + f ) )
        return self.__optimize( f, t )

    def decode(self, i):
        u"""
            Декодирование числа в строку на основе вероятностей в self.freqs
        """
        res = []
        c = None
        while c != '#':
            c = self.__find_interval( i )
            res.append( c )
            (f,t) = self.freqs[c]
            i = int( ( i-f ) * self.max / ( t-f ) )
        return ''.join(res)

    def __freqs2dict(self, freqs_tuples):
        u"""
            Преобразование кортежа вероятностей символов строки в
              словарь интервалов с учетом self.max
        """
        self.freqs = {}
        left = 0
        for (k,v) in freqs:
            self.freqs[k] = ( int(left*self.max), int((left+v)*self.max) )
            left += v

    def __optimize(self, f, t):
        u"""
            Подбор числа из диапазона [f, t) такого, чтобы в нем
            было максимально возможное на интервале число нулевых младших бит
        """
        #return int( (t-f)/2 + f )
        f = int(f)
        t = int(t)
        x = f ^ t
        if not x: return f

        xl = int( ceil( log(x, 2) ) )
        if not xl: return f

        mask_and = ~((1<<xl)-1)
        mask_or  = 1<<(xl-1)

        r = (f & mask_and) | mask_or

        return r

    def __find_interval(self, v):
        u"""
            Ищем интервал, которому принадлежит значение v
        """
        for ( c, (cf, ct) ) in self.freqs.items():
            if v>=cf and v<ct:
                return c

freqs = ( ('a',0.4), ('b',0.2), ('h',0.1), ('r',0.25), ('#',0.05) )
src = 'abraha#'
MAX = 100000000

coder = Arithmetic( freqs, MAX )

print 'SOURCE:  ', src

enc = coder.encode( src )
print 'ENCODED: ', enc

dec = coder.decode( enc )
print 'DECODED: ', dec

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

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

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

Что лучше сожмет ЭК? Конечно можно подать на вход 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

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

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

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