Оптимизация для OpenCL – достаточно трудоемкое дело, на эту тему можно защитить диссертацию, написать книгу-бестселлер и сказочно разбогатеть . Я же начну свой путь к богатству скромно, c поста в блоге. Ниже предполагается, что у читателя уже есть базовое представление об OpenCL, SDK загружен и Hello World написан.

Сегодня хотелось бы отметить приложение, которое поставляется с Intel® OpenCL SDK и имя ему Intel® OpenCL Offline Compiler (x64).

Можно найти несколько реальных применений этому приложению, основная цель которого – компиляция исходного OpenCL кода в код, который OpenCL runtime часть уже способна исполнять.

Сам Offline Compiler выглядит так:

Пример Offline Compiler с загруженым OpenCL кодом.

OpenCL код (слева) после компиляции (в нижнем окне виден отчет о успешной или не очень компиляции) можно просмотреть в виде некого LLVM (Low Level Virtual Machine) байт-кода, или в более традиционном виде x86 ассемблерных инструкции (справа).

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

• простой ( @addLevel2 ) скалярный/поэлементный.
• более продвинутый (@__Vectorized_AddLevel2 ) векторизованный.

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

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

Надеюсь, у вас уже появились вопросы по OpenCL. Не стесняйтесь оставлять их в комментариях – обсудим!

По своей сути AVX, как и его предшественник, SSE, предлагает решение проблемы векторизации. Принцип, заложенный в векторные инструкции процессоров, заключается в упаковке обрабатываемых данных в некий стандартный для железа вид, что само по себе может быть очень выгодно с точки зрения скорости – за один присест обрабатывается сразу несколько значений. Разумеется, за все нужно платить: в нашем случае такой «платой» является соблюдение ряда условий, одно из которых - использование только тех типов данных, для которых оптимизировано «железо». Впрочем, это тема отдельного разговора.

AVX как "первый блин" не вышел комом, но прогресс не стоит на месте и уже вовсю кипит работа над новым набором команд. Через каких-нибудь пару лет можно будет купить новенький процессор базе архитектуры «Haswell». Как это принято в Intel, название архитектуры взято с географической карты, а если быть более точным, - с карты штата Колорадо. Но нас интересует отнюдь не география, а новый набор команд AVX 2.0.

Можно долго углубляться в детали и инструкции AVX 2.0, но начнем с главного:

• AVX способности распространились на целочисленные (integer ) типы и операции с ними.
• Появились инструкции, позволяющие делать GATHER тип операций; при таких операциях не требуется, чтобы данные находились в непрерывных участках памяти.
• FMA (Fused Multiply-Add) - одна инструкция выполняет несколько операций над упакованными данными.
• Добавлены специализированные инструкции по манипуляции битов.

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

В подготовке поможет SDE, софтверный эмулятор новых инструкций, доступный для загрузки с этой страницы: http://software.intel.com/en-us/articles/intel-software-development-emulator/

Для компиляции исходников стоит посмотреть на ранние сборки GCC 4.7.

И самое главное – документация! Первая спецификация (действительно первая публичная спецификация) доступна вот тут - http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/. Владеющим английским также рекомендуется к прочтению вводная статья Introduction to Intel® Advanced Vector Extensions.

В следующем посте постараюсь погрузиться в тему AVX, а пока буду рад ответить на ваши вопросы!

На самом деле, опуская технику программирования с использованием MPI/OpenMP и т.д., кому нужны большие вычислительные ресурсы, описанные, например, тут parallel.ru/russia/russian_clusters.html? Что именно считают на гигантах из этого списка - www.top500.org?

Top 500 еще как-нибудь показывает срезы использования в "Областях применения" ( Application Area), что, конечно, помогает составить некое представление, но… как узнать больше?

Ответ есть, причем довольно хорошо описанный и на большом количестве примеров. Рекомендую посмотреть вот на эту страницу hpc-russia.ru/book_ready.html

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

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

Хотя, если сказать честно – все уже было. Но сегодня стало еще удобнее и даже нагляднее отлаживать перемещение битов по 256 битному полю AVX регистров.

В общем, рекомендую ближе познакомиться с SDE (http://software.intel.com/en-us/articles/intel-software-development-emulator ).

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

Для начала хочу обратить ваше внимание на дополнительный аргумент помощи  - thelp, который раскрывается в довольно длинный набор аргументов, среди которых можно найти и так называемые Debugtrace knobs, где отдельно стоит отметить -debugtrace и -dt_start_int3.

Их использование позволяет нам создать файл отчета debugtrace.out ( имя по умолчанию ), где будут явно видны команды и, главное, их операнды с используемыми значениями.

У меня, например, получается:

TID0: INS 0x00401f4d                     vrcpss xmm7, xmm5, xmm5

TID0:      XMM7 := 00000000_00000000_00000000_3ba57800

XMM7 (doubles) := 0 4.94411e-315

XMM7 (floats)  := 0 0 0 0.00504971

TID0: INS 0x00401f51                     vsubss xmm5, xmm1, xmm0

TID0:      XMM5 := 00000000_00000000_00000000_43460000

XMM5 (doubles) := 0 5.57633e-315

XMM5 (floats)  := 0 0 0 198

TID0: INS 0x00401f55                     vmulss xmm5, xmm5, xmm7

TID0:      XMM5 := 00000000_00000000_00000000_3f7ff5a0

XMM5 (doubles) := 0 5.26353e-315

XMM5 (floats)  := 0 0 0 0.999842

Здесь явно видно, что vmulss ( скалярное умножение с плавающей точкой ) в виде операндов получает

0.00504971 (XMM7) и 198 (XMM5). Результат остается в XMM5 (0.999842), что согласно моему калькулятору является истиной.

Структура debugtrace.out на самом деле довольно проста, и практически сразу, ну или со второго взгляда можно увидеть последние значения используемых регистров или памяти  J.

Для большего удобства советую также обратить внимание на dt_start_int3, который позволяет «окружать» интересный код для более детального разбора уже из SDE.

Я думаю проблем уже нет или ?

Вкусностей тут много, хотелось бы рассказать об одной из них. Итак, опция - stat или официально perf -stat - Run a command and gather performance counter statistics. Сразу скажу - надо перекомпилировать ядро, или найти уже готовый пакет, в котором будет папка tools/perf. Там же исходники perf, о них мы и будем говорить.

Использование perf простое: - perf stat.
Например: perf stat top. После выполнения top, perf выдаст результаты, наример вот так :


Performance counter stats for 'top':
22.932115 task-clock-msecs # 0.005 CPUs
9 context-switches # 0.000 M/sec
0 CPU-migrations # 0.000 M/sec
354 page-faults # 0.015 M/sec
49301576 cycles # 2149.892 M/sec
46533503 instructions # 0.944 IPC
1418097 cache-references # 61.839 M/sec
35107 cache-misses # 1.531 M/sec
4.827942763 seconds time elapsed


интерпретацией результатов можно заниматься долго, IMHO довольно интересно увидеть как часто менялся процессор - достаточно просто посмотреть на CPU-migrations. Конечно, Perf - нечто большее, чем этот маленький пример.

Дополнительную информацию можно найти тут /tools/perf/Documentation/examples.txt, или тут

В частности по поводу ORDERED все явно можно увидеть прямо тут (графики кликабельны):

Cтандарное поведение:

Пару слов от себя - вы, наверное, заметили характерные всплески расходов в compact версии при "заполнении" физического ядра?

Если посмотреть на поведение расходов при синхронизации, то получим следующие картинки:

Ну и стандартное поведение:

Пару слов от себя: поведение ATOMIC довольно линейное по сравнению с другими вариантами.

И по планировщикам, о чем можно говорить еще больше и шире:

По умолчанию же:

От себя: GUIDED и DYMANIC - "большое зло" при неправильном использовании.

Стоит сказать, что разное количество OpenMP потоков регулировалось с помощью переменной окружения KMP_AFFINITY.

А если включить verbose у OpenMP, то можно увидеть еще больше интересного, например как именно и куда возможно положить внутренний OpenMP поток:

Compact:

OMP: Info #149: KMP_AFFINITY: Affinity capable, using global cpuid instr info
OMP: Info #154: KMP_AFFINITY: Initial OS proc set respected: {0,1,2,3,4,5,6,7}
OMP: Info #156: KMP_AFFINITY: 8 available OS procs
OMP: Info #157: KMP_AFFINITY: Uniform topology
OMP: Info #159: KMP_AFFINITY: 1 packages x 4 cores/pkg x 2 threads/core (4 total cores)

OMP: Info #160: KMP_AFFINITY: OS proc to physical thread map ([] => level not in map):
OMP: Info #170: KMP_AFFINITY: OS proc 0 maps to package 0 core 0 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 4 maps to package 0 core 0 thread 1
OMP: Info #170: KMP_AFFINITY: OS proc 1 maps to package 0 core 1 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 5 maps to package 0 core 1 thread 1
OMP: Info #170: KMP_AFFINITY: OS proc 2 maps to package 0 core 2 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 6 maps to package 0 core 2 thread 1
OMP: Info #170: KMP_AFFINITY: OS proc 3 maps to package 0 core 3 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 7 maps to package 0 core 3 thread 1

OMP: Info #144: KMP_AFFINITY: Threads may migrate across 1 innermost levels of machine

OMP: Info #147: KMP_AFFINITY: Internal thread 0 bound to OS proc set {0,4}
OMP: Info #147: KMP_AFFINITY: Internal thread 1 bound to OS proc set {0,4}
OMP: Info #147: KMP_AFFINITY: Internal thread 2 bound to OS proc set {1,5}
OMP: Info #147: KMP_AFFINITY: Internal thread 3 bound to OS proc set {1,5}
OMP: Info #147: KMP_AFFINITY: Internal thread 4 bound to OS proc set {2,6}
OMP: Info #147: KMP_AFFINITY: Internal thread 5 bound to OS proc set {2,6}
OMP: Info #147: KMP_AFFINITY: Internal thread 6 bound to OS proc set {3,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 7 bound to OS proc set {3,7}

Scatter:

OMP: Info #149: KMP_AFFINITY: Affinity capable, using global cpuid instr info
OMP: Info #154: KMP_AFFINITY: Initial OS proc set respected: {0,1,2,3,4,5,6,7}
OMP: Info #156: KMP_AFFINITY: 8 available OS procs
OMP: Info #157: KMP_AFFINITY: Uniform topology
OMP: Info #159: KMP_AFFINITY: 1 packages x 4 cores/pkg x 2 threads/core (4 total cores)
OMP: Info #160: KMP_AFFINITY: OS proc to physical thread map ([] => level not in map):
OMP: Info #170: KMP_AFFINITY: OS proc 0 maps to package 0 core 0 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 4 maps to package 0 core 0 thread 1
OMP: Info #170: KMP_AFFINITY: OS proc 1 maps to package 0 core 1 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 5 maps to package 0 core 1 thread 1
OMP: Info #170: KMP_AFFINITY: OS proc 2 maps to package 0 core 2 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 6 maps to package 0 core 2 thread 1
OMP: Info #170: KMP_AFFINITY: OS proc 3 maps to package 0 core 3 thread 0
OMP: Info #170: KMP_AFFINITY: OS proc 7 maps to package 0 core 3 thread 1
OMP: Info #144: KMP_AFFINITY: Threads may migrate across 1 innermost levels of machine

OMP: Info #147: KMP_AFFINITY: Internal thread 0 bound to OS proc set {0,4}
OMP: Info #147: KMP_AFFINITY: Internal thread 1 bound to OS proc set {1,5}
OMP: Info #147: KMP_AFFINITY: Internal thread 2 bound to OS proc set {2,6}
OMP: Info #147: KMP_AFFINITY: Internal thread 3 bound to OS proc set {3,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 4 bound to OS proc set {0,4}
OMP: Info #147: KMP_AFFINITY: Internal thread 5 bound to OS proc set {1,5}
OMP: Info #147: KMP_AFFINITY: Internal thread 6 bound to OS proc set {2,6}
OMP: Info #147: KMP_AFFINITY: Internal thread 7 bound to OS proc set {3,7}

и Default:

OMP: Info #149: KMP_AFFINITY: Affinity capable, using global cpuid instr info
OMP: Info #154: KMP_AFFINITY: Initial OS proc set respected: {0,1,2,3,4,5,6,7}
OMP: Info #156: KMP_AFFINITY: 8 available OS procs
OMP: Info #157: KMP_AFFINITY: Uniform topology
OMP: Info #159: KMP_AFFINITY: 1 packages x 4 cores/pkg x 2 threads/core (4 total cores)
OMP: Info #147: KMP_AFFINITY: Internal thread 0 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 1 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 2 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 4 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 3 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 5 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 6 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 7 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #149: KMP_AFFINITY: Affinity capable, using global cpuid instr info
OMP: Info #154: KMP_AFFINITY: Initial OS proc set respected: {0,1,2,3,4,5,6,7}
OMP: Info #156: KMP_AFFINITY: 8 available OS procs
OMP: Info #157: KMP_AFFINITY: Uniform topology
OMP: Info #159: KMP_AFFINITY: 1 packages x 4 cores/pkg x 2 threads/core (4 total cores)

OMP: Info #147: KMP_AFFINITY: Internal thread 0 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 1 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 2 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 3 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 4 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 5 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 6 bound to OS proc set {0,1,2,3,4,5,6,7}
OMP: Info #147: KMP_AFFINITY: Internal thread 7 bound to OS proc set {0,1,2,3,4,5,6,7}

Теперь вполне возможно ответить и на те вопросы, которые еще не заданы и/или казались очевидными. Как говорится - лучше один раз увидеть, чем 100 раз поговорить. Теперь вы увидели...

За сим прощаюсь, комментарии и вопросы - always welcome

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

Один из последних моих примеров показал, что в одном из продуктов известной компании Х применение OpenMP как быстрого и довольно простого подхода позволило ускорить выполнение функций коррекции цвета практически на 30%. Причем так как использовалось две функции со своим независимым использованием OpenMP внутри, вынос OpenMP во внешний цикл с последующим объединением этих функций в одну большую был просчитан как нецелесообразный по затратам драгоценного времени разработчиков и не приносящий больших выгод (не более 3%).

Но давайте вспомним о PRIVATE, FIRSTPRIVATE, COPYPRIVATE, COPYIN.
IMHO лучше один раз увидеть, чем много раз проговорить. Поэтому делюсь первой долей информации, которая показывает результаты одного из доступных epcc OpenMP microbenchmarking, запущенных на Core i7 :

(8 логических процессоров)
где время накладных расходов по Y, и размерность используемых переменных по оси X .

А теперь если мы ограничим OpenMP для использования только 1го логического процессора:

OpenMP имеет возможность устанавливать affinity, то есть ограничивать созданные потоки на определенных логических процессорах, но в представленных данных применялась стандартная схема - использование всех логических процессоров (OS processor). Другие варианты - compact (для каждого след. потока пытаться использовать следующее по топологии процессора ядро), scatter (противоположность compact)

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

Я набрал "уже" 36 различных срезов/чартов (Core i7, на Nehalem EP ситуация не менее интересная и более объемная - 62 среза/чарта), и если будет интересно - будем шагать и обсуждать вместе и дальше...

Apple все шире и шире рассказывает о своем виденье - встречайте: Grand Central Dispatch,
одно из далеко немногих, но качественных улучшений в новейшей OS от Apple: Snow Leopard

В принципе и опять же - все как бы просто: Появляеться некое расширения языка ( языков если быть точным : C/C++, Objective-C ) именующее себя блоком (block) и описываеться например так:
x = ^{ printf("hello world\n"); }
В дальнейшем эти блоки формируються для последующего запуска из очереди и по мере наличия ресурсов. Причем изначально говорится о довольно быстром создании подобных блоков и постановки их в очередь, то есть об очень маленьком overhead при работе.
Есть реальные примеры где подобные блоки используються вместо например критических секций в "банковском коде"
Это конечно довольно критическое расширение языка, однако работает.
Несколько печально что многое по этой теме еще под некоторым NDA а то можно было бы показать Вам и больше.

Я думаю что этот немного короткий но информативный пост позволит немного лучше очертить горизонты, а больше - насколько я помню в Сентябре Snow Leopard is out и обо всем можно будет говорить больше и полнее, с деталями.

Хинт: википедия уже знает кое что об Grand Central Dispatch.

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

Одно из главных и принципиальных изменений это изменения базовых типов, с которыми работают инструкции, а вернее их расширения до 256 бит вместо 128 т.е в два раза.

Другими словами - с SSE одновременно можно проводить операции с четырьмя переменными типа float, а с AVX - c восемью.

Уже доступны компиляторы, эмуляторы, но не само железо, харт - его стоит ожидать познее в следующем году или типа того

Доступны так же первые тулзы которые должны помочь в процессе разработки и сообственно дальнейшей оптимизации продукта.

Как, я думаю, все уже слышали о whatif.intel.com - сайт который хостит многие открытые разработки/наработки и "как бы" продукты.

Почему "как бы" - в силу того что это процесс исследования необъятной предметной области, исследования ведеться и в открытом режиме, где Ваши комментарии очень даже приветствуються!

Так вот - 1 Апреля (причем не шутка как проект так и его анонс) вышел в свет так называемый Intel® Architecture Code Analyzer for AVX Instruction set (IACA)

Который стараеться на основе использования AVX инструкций показать общую картину использования Портов процессора, вместе с вопросами тайминга как Latency/Throughput.

Cтоит немного объяснить что подразумеваеться под понятием "порты процессора":

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

- Один из таких модулей - Execution Core (исполнительный модуль как следует из названия ) содержит в себе дальнейшее разделение на так называемые Порты и Исполнительные Юниты (Execution Units)

Вот именно эти самые Порты (пронумерованы от 0 до 5 ) и являються воротам к исполнению команд в последующих Execution Unit(s). Здесь стоит сказать что они (Execution Unit) не универсальны сами по себе и могут выполнять только предопределенного типа работу.

Так, например операции над типом Integer в SSE инструкциях подготавливаться для дальнейшего исполнения

ТОЛЬКО внутри Порта 0 или 5 , а вот неSIMD Integer  - могут на 0,1,5 . Сохранение данные - только Порт 4 , а вот чтение - только Порт 2.

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

(Достаточно обширно данная тема описана в Intel Manuals и в частности Intel® 64 and IA-32 Architectures Optimization Reference Manual)

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

(я намеренно опускаю здесь вариант Out-Of-Order исполнения )

Теперь должна быть понятна цель IACA - показать и  попытаеться оценить все эти зависимости, если они есть.

Само по себе использование IACA довольно простое, например так:

 #include "iacaMarks.h"
 ...
 for (j=0; j<N; j++){
IACA_START
     a[j] = b[j]+scalar*c[j];
IACA_END
   }


Oчень советую посмотреть IACA User Guide и в частности Раздел 5 - Analysis and Optimization Example для примеров возможной оптимизации.
ну и на последок, главная ссылка - http://software.intel.com/en-us/articles/intel-architecture-code-analyzer/

PS Где взять AVX компилятор и эмулятор ? - читайте Frequently Asked Questions по линку выше...

Как всегда - хочется посмотреть на что то интересное, а главное новое.

Взял я тут "практически" навскидку один open source проект и думаю дай займусь, может чего и выйдет

Кстати, для тех что не совсем в курсе - Pixie (www.renderpixie.com), проект который я взял, это RenderMan-like photorealistic renderer.

RenderMan же - это продукт, я думаю многим известной, компании Pixar, ну той, что много мультиков/фильмов "разукрашивает".

Вот кстати большой список фильмов с активным участием уважаемой компании Pixar - https://renderman.pixar.com/products/whatsrenderman/movies.html

Ну вообщем "дело было вечером, делать было нечего" (с) чей то.

Благо Pixie собрался из исходников быстро (на Linux, на Windows немного не так ) и PTU был настроен ранее.

PTU это Intel® Performance Tuning Utility доступный на whatif.intel.com или более прямая ссылка - http://software.intel.com/en-us/articles/intel-performance-tuning-utility/ 

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

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

те порядка 37% общего времени мы крутимся в одной из функций - lookupPixel и общее время работы :

time /opt/pixie/bin/rndr -t:4 ./Beauty_Pass1.rib

real 0m50.973s

Кстати по умолчанию рендер будет использовать 2 треда для вычислений, но у меня 4 ядра запаковано в процессор - поэтому я говорю использовать их все с помощью флага -t:4

Казалось бы ну вот тут мы сразу и в недостатки/нехватку кэша и попадаем. Вот тут и надо вспомнить на чем теория строиться

REYES ( Renders Everything You Ever Saw  ) алгоритм изначально пытаеться ограничить себя по использованию памяти. Молодцы автора что так думали, да и не было у них в те, далекие от сегодня, времена достаточно компьютерной памяти для даже одного фрейма, а хотелось то фильм делать.

ВООБЩЕМ , стоит посмотреть поглубже ибо "авось" тоже забывать не стоит.

Углубимся дальше в код с помощью PTU и видим:

те использование access (причем довольно интересным способом , с помощью define ) примерно и составляет изначальную картину в 85,967 самплов.

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

ну что же - посмотрим и сюда:

где видно что что то забавное происходит возле add eax,01h , границы которой с успехом "потребляют" 21263 из 30337 сэмплов по CPU_CLK_UNHALTED.CORE , причем только в одном вызове access. Cтрока 799 слева от инструкции (Line) ссылается на access(x,y) .

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

Вот тут и надо прикинуть каком С коду эта ассемблерная инструкция может соответсвовать это как бы уже просто:

 790                         CRenderer::textureRefNumber[thread]++;                                              \
 791                         block->threadData[thread].lastRefNumber =   CRenderer::textureRefNumber[thread];    \

где CRenderer::textureRefNumber это просто глобальный массив типа int, те 4 байта каждый элемент.

И если посмотреть на общую картину - становиться понятным: каждый тред берет из пула блок, увеличивает Reference counter на единицу в одном и глобальном массиве.

Я думаю что после моих предыдущих постов и многих других людей - я могу даже не называть имя такой проблемы

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

Я не был уверен стоит или нет писать еще одну запись насчет этой проблемы , но если ранее это были - "подопытные кролики", то сейчас это реальный код существующего приложение.

забегаю вперед скажу что если решить проблему то вполне можно получить следующее улучшение:

time /opt/pixie/bin/rndr -t:4 ./Beauty_Pass1.rib

real    0m35.685s

и следующие претенденты на препарирование всплывают практически сразу.

те примерно 1.38х улучшение по времени.

(Кстати обратите внимание что loopupPixel (RVA 0x38A280) все еще не хочет покидать границы нашего чарта!)

Если хочется код решение - он скоро должен появиться в проекте Pixie, open source.

У меня на данные момент как минимум два решения готово, но буду следовать coding guidelines проекта.

Кстати одно из решений имело проблему

error: alignment of array elements is greater than element

причем специфичную для gcc , где как вариант что то типа

#define CACHE_LINE  64

#ifdef _WINDOWS
#define CACHE_ALIGN __declspec(align(CACHE_LINE))
#else
#define CACHE_ALIGN __attribute__ ((aligned(CACHE_LINE)))
#endif

typedef CACHE_ALIGN struct{
    int value;
    char alignment [CACHE_LINE-sizeof(int)];
} array_int_aligned;

может быть использовано.

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

Eсли будет интересно - в следующих постах я постараюсь сосредоточиться на других проблемах в поисках абсолютной производительности и масштабируемости, таких как:

- использование векторизации

в gcc по умолчанию для O3 , хотя в gcc 4.3.0 разница между O2 и O3 только

>   -fgcse-after-reload                 [enabled]
>   -finline-functions                  [enabled]
>   -fpredictive-commoning              [enabled]
>   -ftree-vectorize                    [enabled]
>   -funswitch-loops                    [enabled]

- использование double как явное и неявное приведение типом / ассемблерный код и производительность

- Thread Profiler in action

 - изменения в алгоритме

Вообщем этот пост уже и так длинный, stay tuned!