В эти холодные дни, когда студенты спокойно отдыхают от сессии, а не-студенты два раза в день мерзнут по дороге на работу и с работы, мы опять решаем, как оформить новые блог(г)ерские футболки для участников Intel Software Network.

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

Итак, в этот раз всё серьезно и более свободно.

Наверняка, у вас есть идея для клёвой футболки блогера/участника ISN. Мы можем воплотить ее в жизнь!

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

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

Самую лучшую идею мы воплотим в жизнь (а это значит, что более 50 человек будут носить на себе ваше творение), а автору идеи, а также самому активному на наш взгляд участнику, отправим свежеиспеченные футболки, как только они приедут к нам из типографии.

Таймлайн: обсуждение лучшей футболки не закончится никогда, но выбирать лучший вариант мы будем 9 марта, сразу после праздников (чтобы веселее было )

До встречи в форуме!

P.S.: Тому, кто догадается, почему мы не предлагаем публиковать картинку в комментариях к этой записи, плюс в карму

P.P.S.: Не воспринимайте последний вопрос серьезно, ответ лежит на поверхности и не отличается уникальностью

Если проводить аналогии, то сети на кристалле (NoC) являются прямым аналогом вычислительных (компьютерных) сетей, которые исторически возникли намного раньше. Вопросы их проектирования, в том числе и в области качества обслуживания, достаточно подробно исследованы в литературе и отражены в технических стандартах. Для компьютерных сетей существуют методы анализа и обеспечения требований к пропускной способности, задержке и её вариации, надежности и т.д. Пришло время разобраться, в чем же отличия компьютерных сетей от сетей на кристалле, которые препятствуют использованию существующих подходов к обеспечению качества обслуживания и вынуждают разрабатывать новые.

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

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

Аргумент в пользу сетей на кристалле: в глобальных сетях, поток данных может проходить через участки, построенные по различным технологиям, отличающимся способами коммутации, разделения среды, маршрутизации и т.д. Например, при звонке с IP-телефона на сотовый телефон, голосовой трафик может сначала проходить через локальную сеть с коммутацией пакетов, затем через сеть ATM с коммутацией соединений и, наконец, через мобильную сеть построенную по третьей технологии (например, UMTS). Чтобы обеспечить выполнение требований качества обслуживания на всем пути от источника к получателю, необходимо учитывать отличия механизмов качества обслуживания в этих типах сетей. Для сетей на кристалле архитектура заранее известна и проблемы связанные с передачей данных между разными типами сетей не актуальны.

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

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

За последнее десятилетие были предложены подходы к проектированию коммуникационных фабрик, призванные обеспечить гарантии качества обслуживания “по построению”. Их можно условно разделить на две категории. Подходы на основе дифференциации трафика (traffic differentiation) решают проблему конкурирующих запросов введением уровней приоритета, соответствующих разным классам трафика. Однако для сложной системы затруднительно определить необходимое количество уровней приоритетов и избежать таких проблем, как инверсии приоритета и истощения ресурсов (starvation).
Проблема инверсии приоритетов заключается в следующем: если в одной из очередей пакетов высокоприоритетному пакету предшествует низкоприоритетный, то продвижение пакета с высоким приоритетом блокируется до тех пор, пока не будет обработан низкоприоритетный пакет. Такая ситуация потенциально приводит к нарушению требований качества обслуживания для высокоприоритетного трафика. Фактически приоритет обслуживания блокирующего пакета повышается по сравнению с тем классом трафика, к которому он принадлежит. Избежать этого можно, например, повсеместным использованием раздельных очередей для буферизации различных классов трафика.

Передача без конкуренции (contention-free transmisson) основывается на той или иной схеме резервирования ресурсов перед началом передачи. Разделение времени обработки, использование мест в очередях, порядок передачи по разделяемым линиям связи, планируются заранее. Если тот или иной ресурс оказывается невостребованным тем, кому он предназначался согласно плану, то он не используется даже при наличии других запросов на этот ресурс.
Используя статическое резервирование, несложно добиться определенных гарантий производительности. Такой подход позволяет оптимизировать архитектуру под конкретное приложение и пригоден для встраиваемых систем, но приводит к низкой утилизация ресурсов в системах на кристалле широкого спектра применения. Это объясняется опять же тем, что поведение узлов сети может сильно изменяться с течением времени. При динамическом резервировании ресурсов, после того как ресурсы уже зарезервированы, удается добиться и гарантий производительности и хорошей утилизации ресурсов. Но сам процесс резервирования может занять длительное время и задержки на стадии резервирования по-прежнему трудно оценить.

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

В ноябре прошлого года сотрудники двух лабораторий (НИВЦ МГУ и ВМК ННГУ) разработали совместный курс по параллельному программированию и победили в международном конкурсе, организованном компанией Informatics Europe.

Конкурсная заявка коллектива МГУ–ННГУ Parallelism & Concurrency: Changing the Landscape of IT-Education получила признание представительного международного жюри конкурса, что подтверждает высокий уровень образования и исследований в Московском и Нижегородском университетах и свидетельствует о качестве образования в России в целом в области суперкомпьютерных технологий.

Informatics Europe – известная международная ассоциация факультетов и исследовательских лабораторий в области Computer Science в Европе и соседних регионах. Основное направление деятельности ассоциации – способствование повышению качества образования и исследований в области информатики и Computer Science.

Награда в конкурсе Informatics Europe Curriculum Best Practices Award присуждается за выдающиеся достижения, способствующие повышению качества образования и привлекательности дисциплины. Отмечается возможность использования образовательных материалов за пределами создавшей их организации. В 2011 году конкурс был направлен на тематику, связанную с параллельными вычислениями (Parallelism and Concurrency), и поддержан грантом компании Intel.

Вручение награды состоялось в рамках ежегодного международного форума European Computer Science Summit. В саммите принимали участие деканы, заведующие кафедрами и ключевые сотрудники ведущих европейских университетов, факультетов, исследовательских институтов в области информатики и Computer Science, а также представители индустрии. В 2011 году форум был проведен в Милане (Италия) с 7 по 9 ноября.

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

С презентацией курса, который получил эту почетную награду можно ознакомиться по ссылке Parallelism & Concurrency: Changing the Landscape of IT-Education (pdf).

Авторы курса:

ННГУ:

• В.П. Гергель, д.т.н., профессор, декан факультета ВМК ННГУ, соруководитель коллектива
• И.Б. Мееров, к.т.н., доцент
• К.А. Баркалов, к.ф.-м.н., старший преподаватель
• А.В. Сысоев, ассистент

МГУ:

• В.В. Воеводин, член-корреспондент РАН, д.ф.-м.н., профессор, заместитель директора НИВЦ ВМК, соруководитель коллектива
• Н.Н. Попова, к.ф.-м.н., доцент
• А.С. Антонов, к.ф.-м.н., старший научный сотрудник
• С.А. Жуматий, к.ф.-м.н., старший научный сотрудник
• О.В. Джосан, к.ф.-м.н., ассистент

Я сам уже почти 3 года участвую в жизни лаборатории ITLab ННГУ и очень рад за преподавателей и коллег.

Еще раз поздравляем!

Вопрос читателям: а как вас учили параллельному программированию в университете?

Хотели бы вы учиться, например, по такому курсу, как Параллельные численные методы?

Не все йогурты одинаково полезны.

Преамбула:
При написании шаблонных параметров обычно принято использовать ключевое слово class, чтобы подчеркнуть, что шаблонный параметр является классом (структурой). Стандарт C++ говорит следующее [п.14.1.2]:

There is no semantic difference between class and typename in a template-parameter.

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

Амбула:
Намедни необходимо было написать шаблонный класс, параметризованный другим шаблонным классом. Было написано:

template <template  <typename T> typename Cl >

Вот тут и возникла проблема - компилятор VC++ 2010 гордо рапортовал об ошибке:

error C2988: unrecognizable template declaration/definition

Компилятор Intel C++ Compiler 12.0 и также возвращал сообщение об ошибке:

error : expected "class"
template <template <typename T> typename Cl >
                                ^

После повторного чтения стандарта, была выяснена причина. Если подробнее рассмотреть синтаксис шаблонных параметров, то можно заметить, что для параметризации шаблонных параметров можно использовать только ключевое слово class [п.14.1.1]:

template < template-parameter-list > class ...[opt] identifier[opt]
template < template-parameter-list > class identifier[opt] = id-expression

Вобщем, проблема локализована и после корректировки исходного кода до:

template <template  <typename T> class Cl >

компиляция проходит успешно в VC++ 2010 и Intel C++ 12.0.

Мораль:
Не всегда ключевые слова typename и class являются синонимами. При объявлении шаблонного параметра другого шаблонного параметра необходимо использовать только ключевое слово class, вместо typename.
И... проглядывайте стандарт C++;)

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

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

В предыдущем посте я немного рассказал об одном из возможных решений - динамической генерации кода. Это реализовано в Intel Array Building Blocks. У этого подхода свои плюсы и минусы. К плюсам следует отнести универсальность и гибкость, к минусам внутреннюю сложность и значительные накладные расходы (ведь сначала код надо сгенерировать).

Вопрос: какие еще существуют решения для оптимизации кода под различные платформы? Попытаемся разобраться в способе, который называется диспетчеризацией (Dispatching).

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

Исходя из того, что простое лучше, чем сложное, можно сделать несколько вариантов кода, каждый из которых функционально идентичен остальным, но оптимизирован под свой набор процессоров. Очевиден и основной недостаток: на каждом CPU необходимо выбрать, какой процесс запустить или какую библиотеку вызвать. Этот минус можно обойти, если использовать дополнительный модуль. Он вызывается в run-time, автоматически определяет тип процессора и предлагает выбрать ветку кода, которая подойдет под текущее "железо" наилучшим образом. Этот модуль называется диспетчером (Dispatcher).

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

Существуют различные реализации диспетчеров. По одной из них (в библиотеке Intel IPP) диспетчер идентифицирует CPU один раз - во время инициализации библиотеки, после чего задает набор внутренних переменных. В соответствии с этим набором библиотечные вызовы из приложения перенаправляются в соответствующие внутренние функции библиотеки. Например, при запуске приложения на Core 2 Duo в 32-битной операционной системе вызов функции ippsCopy_8u() перенаправляется на p8_ippsCopy_8u() - одну из множества реализаций функциональности ippsCopy_8u(), имеющихся в библиотеке.

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

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

В качестве альтернативы можно использовать целочисленные операции, основанные на работе не с одним значением внутри интервала, а с текущими границами. Если арифметический кодер работает в пределах интервала [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

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

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

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

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

Следуя примеру из предыдущей заметки, входная последовательность символов: 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

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

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

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

Вспомнил я о индукции не просто так, а в продолжении темы арифметического кодирования. В прошлый раз мы остановились на том, что определили рекурсивный метод нахождения конечного интервала из которого, в результате, получили код входной последовательности символов. Вот он в двоичной системе счисления: 0.10111110001(2)

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

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

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

Вспомним пример из предыдущей заметки. Длина конечного интервала составила 0.0002. Тогда полученная выше оценка составит 13 бит. Но, итоговое представление заняло только 11 бит. Источником этой несостыковки является тот факт, что мы всегда можем выбрать представление удовлетворяющее обозначенной оценке, но завершающееся непрерывной последовательностью нулей, которые в итоге и обрезаются. Однако, доказано, что среднее количество бит, которые можно сэкономить подобным образом, равно единице, то есть на практике редко удасться сэкономить более одного бита.

Вот такая вот ода математике.