В предыдущем посте я немного рассказал об одном из возможных решений - динамической генерации кода. Это реализовано в 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(), имеющихся в библиотеке.

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

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

Сразу надо признать, что ArBB runtime в значительной степени - это черный ящик, о его внутренней структуре мы знаем немного. Оно и понятно: повара не любят раскрывать рецепты своих блюд. Начнем с общеизвестной информации, не связанной непосредственно с ArBB. Когда приложение скомпилировано, динамически слинковано, находится на исполнении и встречается вызов библиотечной функции, начинает исполняться код самой библиотеки. Таким образом, если в приложении встречается вызов arbb::call(), ArBB берет на себя контроль над вычислениями, а по завершении контроль возвращается к самому приложению.

Дальше идет специфика. «Фишка» ArBB наличии собственной среды исполнения, которая осуществляет динамическую компиляцию с оптимизацией под текущую платформу во время исполнения. Таким образом, первая фаза компиляции - это собственно компиляция С++ кода в исполняемый файл, а вторая - во время работы приложения. Для этого в составе ArBB runtime есть JIT (Just In Time) компилятор, генерирующий бинарный код для исполнения конкретной операции с учетом количества ядер, поддерживаемых процессором SIMD инструкций (SSE, AVX) и т.д. Для чего все это? Проблема в том, что если весь бинарный код будет готов еще до исполнения, то он не может быть оптимален сразу для разного железа. Будет неправдой сказать, что это не пытались обойти без динамической генерации кода. Например, можно положить в библиотеку несколько заранее подготовленных вариантов бинарного кода для одной и той же операции. Когда идет обращение к библиотеке, специальный модуль (Dispatcher) принимает решение, какой вариант лучше всего подойдет для текущей машины. У каждого из подходов есть свои недостатки, обсуждение которых я оставлю за рамками этого поста. Но нужно сказать, что подход с JIT-ом представляется более тяжеловесным с точки зрения накладных расходов, но более легким с точки зрения объема библиотеки и более гибким с точки переносимости и количества поддерживаемого железа.

Теперь нюанс. Дело в том, что JIT генерирует код не всегда. Согласно опубликованной информации, в зависимости от уровня оптимизации ArBB предлагает два варианта. В неоптимизированном случае просто исполняется код, «зашитый» в библиотеку изначально. Случай с оптимизацией более интересен. Здесь JIT компилятор генерирует код требуемой операции на лету, и этот код будет оптимизирован под платфому, на которой идет исполнение. После этого сгенерированный код исполняется. Кроме того, ArBB runtime записывает этот код, чтобы не генерировать его снова, если этот же вызов будет выполнен в приложении еще раз.

Здесь становятся видны сходство и разница между JIT из ArBB и JIT из .NET. И тот и другой получают на вход некую конструкцию (ArBB вызов или IMSL), генерируют бинарный код, и записывают его на случай, если в приложении потребуется выполнить его снова. ArBB JIT генерирует оптимизированный код, чтобы приложение быстро работало там, где оно реально выполняется. Сами приложения, использующие ArBB (насколько я понимаю) - это обычный бинарный код с библиотечными вызовами. .NET же предлагает дополнительный уровень абстракции на уровне приложения (IMSL), в часности, предлагая независимость от языка программирования.

Есть много решений, упрощающих разработку параллельных приложений. Один из первых стандартов в области параллельных технологий – Cilk, разработка которого началась в 1994 году в лаборатории Информатики M.I.T. Кстати, c 2009 года группа разоработчиков Cilk стала частью Intel. В 1997 году появилась первая версия другого решения – OpenMP. Сейчас это одна из наиболее распространенных технологий, ключевыми элементами которой являются конструкции для управления потоками и данными, библиотечные функции и переменные окружения. В 2006 году Intel выпустила Intel® Threading Building Blocks (Intel® TBB), где параллелизм реализован на уровне задач, а в распоряжение разработчиков предоставлены планировщик и потокобезопасные контейнеры. Продукт получился весьма успешным и используется как основа для других решений, в частности, ArBB, на котором остановимся подробнее.

Основная идея – прячем параллельный код по контейнерам.

Intel® ArBB представляет собой расширение C++ новыми классами и функциями, а также собственный runtime. Продукт появился в результате слияния своего предшественника Intel’s Ct Technology c технологией Rapidmind. Cуть ArBB в том, что программист пишет код, похожий на обычный, непараллельный, но использует типы данных, контейнеры и функции из ArBB (например, i32 вместо int, dense вместо vector и т.д.) и указывает, выполение каких функций должен взять на себя ArBB runtime. По умолчанию runtime сам определяет, сколько потоков создать, что каждый из них будет делать, как синхронизовать данные и т.д. Посмотрим как это выглядит на деле. Для этого разберем небольшой пример кода, в котором используется ArBB.

Hello ArBB! Как это выглядит на практике?

Одна из простых типовых задач – подсчет суммы элементов в массиве целых чисел. Код с использованием ArBB выглядит следующим образом.

#include <iostream>
#include <arbb.hpp>
// включение основного include файла ArBB

template <typename T>
void f(arbb::dense<T> arr, T& res)
// arr – исходный контейнер, в res – записывается результат
{
    res = arbb::add_reduce(arr);
    // использование встроенной ArBB функции
    // для подсчета суммы элементов
}

int main()
{
    int arr_size = 500;    // размер массива
    int* arr = (int*)arbb::aligned_malloc(sizeof(int)*arr_size);
    // выделение памяти под массив
    // использование arbb::aligned_malloc
    // гарантирует корректную работу ArBB с массивом
    for(int i = 0; i<arr_size;i++)  // инициализация массива
        arr[i]=i;
    arbb::dense<arbb::i32> arbb_arr;
    // декларируем контейнер ArBB
    arbb::bind(arbb_arr, arr, arr_size);
    // связываем исходный массив и контейнер ArBB
    arbb::i32 result;
    // объявляем переменную для записи результата
    arbb::call(f<arbb::i32>)(arbb_arr, result);
    // вызов ArBB runtime для выполнения функции f

    std::cout << arbb::value(result);
    // Доступ к ArBB скалярам осуществляется через arbb::value

    return 0;
}

В примере реализована функция f, принимающая два аргумента. Первый – исходный контейнер dense, что в терминах ArBB является аналогом vector. Cумму его элементов мы и будем считать. Второй аргумент нужен, чтобы вернуть результат.

Одна из «фишек» ArBB в том, что в продукте реализованы сотни полезных функций для всевозможных типовых операций над разными наборами данных. Это сильно облегчает жизнь: во-первых, не надо заботиться о реализации того или иного алгоритма, а во-вторых не надо городить много вложенных циклов с зависящими друг от друга параметрами, в результате код становится более читаемым. Одна из таких встроенных в ArBB функций – add_reduce, возвращает сумму элементов в контейнере.

В main() создается и инициализируется массив, объявляется ArBB контейнер, и происходит связывание массива и контейнера. Зачем все это? В использовании ArBB есть нюанс: ArBB может производить вычисления только в своем пространстве и только с ArBB типами (нельзя передать C++ массив напрямую в f). Теперь же массив и ArBB контейнер содержат одни и те же данные. Далее объявляем ArBB переменную для записи результата и вызываем функцию f. arbb::call(имя)(аргументы) – это и есть вызов ArBB runtime с указанием выполнить функцию, исполнение происходит в ArBB пространстве. Осталось вывести результат. Единственное, что надо не забыть – это прописать зависимость от библиотеки ArBB в свойствах проекта или напрямую в командной строке при компиляции, например

icl /D WIN32 /D NDEBUG /EHsc application.cpp /link arbb.lib

Что имеем в результате: минусы

• Написание и разбор ArBB кода может показаться утомительным, особенно с непривычки. Разработку осложняют требования использовать специальные типы данных. Необходимо организовать отдельное пространство для ArBB вычислений, а также связывать контейнеры из C++ и ArBB.
• Собственный runtime приносит дополнительные накладные расходы.

Что имеем в результате: плюсы

• Гарантированное отсутствие data races & deadlocks.
• Высокоуровневый API: сотни операций с контейнерами, в том числе и многомерными, делаются в одну строчку посредством встроенных функций, не загромождая код и мозг ненужными деталями.
• Собственный runtime обеспечивает отличную переносимость приложений. Не надо ничего изменять, чтобы приложение оптимально работало и на multi-, и на manycore системах, будь то 4-х ядерный десктоп, 16-core двухсокетный сервер или 32-ядерная MIC карта. Также нет необходимости оптимизировать приложение под конкретный набор SIMD инструкций. Это большое преимущество как с точки зрения цены поддержки приложения, так и в случае если вы не знаете заранее, на каком железе оно будет запускаться.

Лучшее место для начала знакомства с ArBB, пожалуй, здесь. Продукт сейчас в Beta стадии.