Конвейерные разнородные вычисления

ЗАГРУЗИТЬ PDF[PDF 657KB]

Содержание

1. Аннотация

2. Процессоры семейств Intel® Core™ и Atom™ и разнородная архитектура обработки

3. Введение

4. Модель

5. Требования к памяти

6. Реализация — TBB+OpenMP+OpenCL

7.Показатели производительности

8. Заключение

9. Об авторе

10. Справочные материалы

11. Уведомления

1. Аннотация

В большинстве случаев эффекты, применяемые к изображениям и видео, состоят из двух и более этапов. Разработчики программного обеспечения зачастую применяют их последовательно, по одному. Самый простой способ повысить производительность для таких алгоритмов — оптимизировать каждый этап по отдельности с помощью векторизации, многопоточности и оффлоада обработки графики на ГП. Но и в этом случае этапы обрабатываются последовательно. Процессор Intel® предоставляет множество возможностей для оффлоада и параллельной обработки алгоритмов для наивысшей производительности при экономном расходовании электроэнергии. Разработчики всегда могут оптимизировать алгоритм для одного устройства (т. е. ЦП или ГП), но они упускают возможности для значительного повышения производительности, поскольку не используют другие вычислительные компоненты «системы на кристалле». Ситуация усложняется, если приложение распределяет нагрузку между разными устройствами при параллельной обработке. В этой статье мы рассмотрим эффективный способ использования всех доступных ресурсов ЦП Intel® с помощью конвейерной обработки ЦП и кода OpenCL.

2. Процессоры семейств Intel® Core™ и Atom™ и разнородная архитектура обработки

Семейства процессоров Intel® Core™ и Atom™ представляют собой решения «система на кристалле», использующие различные ресурсы для разнородных вычислений и обработки мультимедиа. На рис. 1 показана компоновка кремниевого кристалла процессора Intel® Core™ M.

Рисунок 1. Компоновка кремниевого кристалла процессора Intel⁹ Core™ M. Эта «система на кристалле» содержит 2 ядра ЦП, показанных в виде оранжевых прямоугольников. Синим прямоугольником показан видеоадаптер Intel⁹ HD Graphics 5300. Это реализация Intel⁹ Processor Graphics в один слой [7]

Микропроцессоры Intel® представляют собой сложные «системы на кристалле», в которые интегрировано несколько ядер ЦП, видеоадаптер Intel® Processor Graphics и другие компоненты. Все перечисленные компоненты физически выполнены в виде одного кремниевого кристалла. В архитектуре используется несколько областей с различной тактовой частотой: по одной такой области для каждого ядра ЦП, еще одна область для ГП и еще одна — для кольцевой шины подключений. Архитектура «систем на кристалле» разработана таким образом, чтобы допускать возможность расширения, но при этом обеспечивать высокоэффективную передачу сигналов между компонентами.
Рисунок 2. «Система на кристалле» с процессором Intel⁹ Core™ M с кольцевой архитектурой шины подключений [7]

В процессорах Intel® Core™ 2-го поколения были расширены возможности обработки разнородных данных мультимедиа за счет введения Intel® Quick Sync Video (Intel® QSV) в Intel® Media SDK [9]. Эта технология сохранилась в процессорах Intel® Core™ 3-го поколения, где также была добавлена поддержка OpenCL™ 1.2. Это решение дало возможность выполнять разнородные вычисления на ГП Intel® Processor Graphics [7]. В новых процессорах Intel® Core M увеличена гибкость и повышено удобство программирования за счет поддержки OpenCL™ 2.0. Процессоры Intel® Core™ уже поддерживали общую физическую память, поэтому приложения могли передавать данные между ЦП и ГП. В OpenCL™ 2.0 поддерживается общая виртуальная память, благодаря чему приложения могут бесшовно разделять структуры данных между этими двумя устройствами.

3. Введение

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

Рассмотрим общую модель выполнения алгоритмов, состоящих из N этапов.

Рисунок 3. Общая модель выполнения алгоритмов

Пусть T_i будет временем, необходимым на выполнение i-го этапа. Тогда общее время выполнения можно вычислить как ∑ T_i.

Самый простой способ оптимизации состоит в настройке производительности каждого этапа в отдельности с помощью настройки скалярного кода, многопоточности, векторизации [1] или оффлоада части задач на ГП (OpenCL и пр.). Такой подход годится в качестве первого шага, но здесь возможности наращивания производительности ограничены. Например, ускорение одного из пяти этапов вдвое может привести к повышению общей производительности приблизительно лишь на 10 %, если выполнение всех этапов занимает относительно одинаковое время.

Можно добиться параллельной обработки, запустив несколько эффектов одновременно, как поясняется в статье Эрика Рида, Николаса Чена и Ральфа Джонсона «Распараллеливание конвейера с помощью конструкций TBB» [2]. К сожалению, это возможно лишь в случае, если одновременно доступно несколько сегментов входных данных (кадров). При редактировании фотографий, к примеру, этот подход неприменим. Кроме того, этот метод может недостаточно эффективно использовать доступные ресурсы, а также расходовать больше памяти. Тем не менее, этот метод следует учитывать в расчетах, поскольку он может быть полезен для многих алгоритмов обработки видео.

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

4. Модель

Для упрощения обсуждения рассмотрим краткую версию эффекта, содержащую всего два этапа.

Рисунок 4. Алгоритм с двумя этапами

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

Рисунок 5. Сегментная версия алгоритма

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

Пусть t1 и t2 — время выполнения этапа 1 и этапа 2. Тогда общее время выполнения будет равно T = t1 + t2. Если не учитывать издержки, связанные с управлением потоками и синхронизацией, то можно оценить фактическое время как
T = max(t1, t2) + (t1 + t2)/N,
где N — количество сегментов. Поскольку lim_N→∞T = max(t1, t2), теоретически можно скрыть выполнение одного из эффектов и сократить фактическое время на .

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

5. Требования к памяти

Как было сказано в начале, мы покажем, как предлагаемый алгоритм может снизить требуемый объем памяти и повысить локальность данных. Пусть S представляет входные данные (буфер изображения, например), и предположим, что нам требуется S места для промежуточных данных и еще столько же памяти для выходных данных. Тогда общий объем требуемой памяти составит 3S. В предлагаемой модели нам нужно только два промежуточных буфера размером S/N, поэтому общий объем требуемой памяти будет равен

M = (2 + 2/N)S, то есть <3S для всех N > 2. Таким образом, можно ожидать, что общий объем требуемой памяти уменьшится на
Также отметим, что .

Теперь подсчитаем количество одновременно задействованных буферов: 2 * входных +
2 * промежуточных + 1 * выходнойв случае, если этап 2 также использует входные данные. Тогда общий объем требуемой памяти составит m = 5S/Nв отличие от 2Sдля базовой реализации, то есть в 1,6 раза меньше для N = 4 и более чем в 6 раз меньше для N = 16.

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

6. Реализация — TBB+OpenMP+OpenCL

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

Сначала мы применили «сегментированные» версии алгоритмов этапа 1 (ЦП/AVX2) и этапа 2 (OpenCL), как показано на рис. 5, и использовали OpenMP для повышения производительности на этапе 1 и задействования всех доступных ядер ЦП.

Для применения конвейерной обработки и параллельного выполнения мы использовали Intel TBB [5] — этот компонент с открытым исходным кодом можно использовать вместе с компилятором Intel C/C++. Чтобы использовать tbb::pipeline для конвейерной обработки в программах, определите классы этапов (tbb::filter) и структуру маркеров. Маркер — это то, что передается между этапами и включает информацию о сегментах, а также другие промежуточные данные. TBB управляет передачей маркера следующему этапу в виде входного параметра оператора (void*).

Для наивысшей производительности используйте возможности «нулевого копирования» OpenCL [6], предоставляемые архитектурой Intel® Graphics, или общей виртуальной памяти (SVM), доступной в наборе технологий OpenCL 2.0 и поддерживаемой графическими процессорами Intel^® Graphics начиная с семейства Broadwell.

struct token_t {
	void *buffer; 	// intermediate buffer
	int tile_id;		// Tile number
};

class Stage1: public tbb::filter {
public:
	void* operator() (void *) {
		if(tile_id == num_tiles)
			return null;			// tells TBB to stop pipeline execution

		// Create token and select preallocated buffer
		token_t *t=new token_t();
		t->tile_id = tile_id++;
		t->buffer = buffers[tile_id % 2]; // select one of the buffers

		DoStage1_CPU(t, input);		// Process tile on CPU

		return t;	// Transfer intermediate data to the next stage
	}
};


class Stage2: public tbb::filter {
public:
	void* operator(void* token) {
		token_t *t = (token_t*)token;	// Receive data from the previous stage

		DoStage2_OpenCL(output, t);	// Do second stage on the Processor Gfx
							// and write output data

		delete t;				// Destroy token
		return 0;				// Finish pipeline
	}
}


После этого конвейерная обработка (tbb::pipeline [4]) выглядит гораздо проще.
// Create and initialize stages
Stage1 s1(input, W, H);
Stage2 s2(input, output, W,H);

// Create pipeline
tbb::pipeline ppln;
// Add filters(stages)
ppln.add_filter(s1);
ppln.add_filter(s2);
// Run 2 pipelines
// 	One will be executed on the CPU,
//     while the other one on Processor Gfx
//     and vice versa on the next “step”
ppln.run(2);

7. Показатели производительности

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

Мы провели эксперименты на процессоре Haswell i7-4702HQ с частотой 2,2 ГГц с различным количеством сегментов и получили прирост производительности в 1,7 раз по сравнению с последовательной обработкой. Мы также обнаружили, что для нашего алгоритма на данной конкретной платформе оптимальное количество сегментов составляет от 4 до 8.

Рисунок 7. Время выполнения эффекта

8. Заключение

В этой статье мы описали эффективный алгоритм, распределяющий нагрузку между доступными вычислительными ресурсами и обеспечивающий прирост производительности в 1,7 раза за счет выполнения алгоритма одновременно на ЦП и ГП. Этот подход можно расширить, используя другие устройства и другие возможности процессоров Intel®. Одним из самых популярных аппаратных компонентов в Intel Processor Graphics является Intel® Quick Sync Video (QSV) [9]. Приложения могут использовать аналогичный подход для разделения этапов предварительной обработки с последующей передачей таких сверхбыстрых блоков для кодирования кадров.

9. Об авторе

Илья Альбрехт уже 5 лет работает в корпорации Intel на должности инженера по разработке приложений. Кроме того, он занимается оптимизацией алгоритмов, архитектурой современных ЦП и OpenCL. Илья имеет диплом магистра в области математики и информационной безопасности. Он любит путешествовать по красивым местам Аризоны и Калифорнии со своей женой

10. Справочные материалы

1. «Средства векторизации Intel», https://software.intel.com/ru-ru/intel-vectorization-tools
2. «Распараллеливание конвейера с помощью конструкций TBB», Эрик Рид, Николас Чен, Ральф Джонсон https://www.ideals.illinois.edu/bitstream/handle/2142/25908/reedchen johnson.pdf ?sequence=2
3. «Драйверы и выполняемые модули OpenCL™ для архитектуры Intel®», https://software.intel.com/ru-ru/articles/opencl-drivers
4. «Класс pipeline», http://www.threadingbuildingblocks.org/docs/help/reference/algorithms/pipelinecls.htm
5. «Threading Building Blocks (Intel® TBB)», https://www.threadingbuildingblocks.org/
6. «Нулевое копирование буфера OpenCL в OpenCL 1.2», руководство по оптимизации OpenCL, https://software.intel.com/ru-ru/node/515456
7. «Intel® Processor Graphics», https://software.intel.com/ru-ru/articles/intel-graphics-developers-guides.
8. «Intel® SDK для приложений OpenCL™», https://software.intel.com/ru-ru/intel-opencl
9. «Intel® Media SDK», https://software.intel.com/ru-ru/vcsource/tools/media-sdk-clients

11. Уведомления

ИНФОРМАЦИЯ В ДАННОМ ДОКУМЕНТЕ ПРИВЕДЕНА ТОЛЬКО В ОТНОШЕНИИ ПРОДУКТОВ INTEL. ДАННЫЙ ДОКУМЕНТ НЕ ПРЕДОСТАВЛЯЕТ ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМОЙ ЛИЦЕНЗИИ, ЛИШЕНИЯ ПРАВА ВОЗРАЖЕНИЯ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ. КРОМЕ СЛУЧАЕВ, УКАЗАННЫХ В УСЛОВИЯХ И ПРАВИЛАХ ПРОДАЖИ ТАКИХ ПРОДУКТОВ, INTEL НЕ НЕСЕТ НИКАКОЙ ОТВЕТСТВЕННОСТИ И ОТКАЗЫВАЕТСЯ ОТ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ В ОТНОШЕНИИ ПРОДАЖИ И/ИЛИ ИСПОЛЬЗОВАНИЯ СВОИХ ПРОДУКТОВ, ВКЛЮЧАЯ ОТВЕТСТВЕННОСТЬ ИЛИ ГАРАНТИИ ОТНОСИТЕЛЬНО ИХ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, ОБЕСПЕЧЕНИЯ ПРИБЫЛИ ИЛИ НАРУШЕНИЯ КАКИХ-ЛИБО ПАТЕНТОВ, АВТОРСКИХ ПРАВ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

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

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

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

Копии документов с порядковым номером, ссылки на которые содержатся в этом документе, а также другую литературу Intel можно получить, позвонив по телефону 1-800-548-47-25 либо на сайте http://www.intel.com/design/literature.htm

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

Intel, эмблема Intel, Core, Iris и Iris Pro являются товарными знаками корпорации Intel в США и в других странах.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

OpenCL и логотип OpenCL являются товарными знаками Apple Inc. и используются с разрешения Khronos.

© Intel Corporation, 2014. Все права защищены.