И вот - гран финале. Сегодня Google объявила о выходе собственного языка программирования Go. Начался обратный отсчет времени до тотального покорения галактики.

Я сейчас сижу на сайте http://golang.org/, читаю документацию и паралелльно общаюсь со знатоками. Не скрою, мне трудно, потому что никакой я не программист  - так, тестировщик. Пока на вид ничего страшного: в FAQ много уклончивых формулировок и маркетингового бла-бла, и по соседству признается, что даже в самой великой и ужасной Google до массового использования мегаязыка пока не дошло.

И вот вроде всего первый день пошел, а отзывов в Интернете уже пруд пруди. Кто-то называет странным плодом любви Python с C++. Кто-то придумал имя для людей, программирующих на нем - Goпники. Есть голоса, предрекающие кончину во младенчестве, а есть и оптимисты, гарантирующие скорый переход на Go 99,9 процентов всех программистов мира. Не 100, потому что этих фортранщиков все равно не переубедить. Они переживут даже ядерную зиму.

Скептики могут сказать, что существует несколько тысяч языков программирования, и одним больше, одним меньше - не повод тратить виртуальные чернила. Но тут ведь как в известном анекдоте: "я не знаю, кто в машине, но шофер у него Брежнев". Людские и финансовые возможности Google таковы, что если в компании решат - Go попрет стремительным домкратом. Коллеги по бизнесу сначала посмеются, потом помолчат, а потом запрутся в маленьких комнатках и начнут бояться любого звука. Помните, как хихикали над Microsoft, когда корпорация вышла на рынок приставок? Вот, недавно вышло исследование - на долю Xbox приходится уже 49% отечественного рынка, да и на мировом одни сплошные поводы для оптимизма. В общем, главное - захотеть.

Но захочет ли Google? Чтобы понять это, язык врага надо знать и понимать немного лучше, чем это под силу экс-тестировщику. Поэтому обращаюсь к вам, уважаемые коллеги. Каковы первые впечатления? Насколько доработан язык на сегодняшний день? Правда ли, что он заточен исключительно под серверные приложения, а остальным просьба не беспокоится? Что может заставить лично вас серьезно сесть на Go? И - главное - нужен ли индустрии новый язык программирования? И нужен ли ей Go?

Меня пока порадовало вот что. В беседе с одним из экспертов, автором нескольких серьезных книг по программированию, который пока решил остаться неизвестным, первым делом был озвучен интерес -насколько применение Go облегчает распараллеливание?

Дорогой Дмитрий Оганезов! Даже если Big Brother нас таки заглотит, мы будем знать, что идея пошла в массы, и если бы не он - все бы у нас получилось. Но может еще и получится, а?

В частности по поводу 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 среза/чарта), и если будет интересно - будем шагать и обсуждать вместе и дальше...

Одно из главных и принципиальных изменений это изменения базовых типов, с которыми работают инструкции, а вернее их расширения до 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 по линку выше...

Есть три способа добыть видео для просмотра на PSP. Первый - и теоретически самый простой - купить диск UMD-Video. Но в России их продают крайне вяло (настолько, что они мне в наших краях ни разу на прилавке не встретились), и русскоязычными звуковыми дорожками там не пахнет. Второй - добыть уже готовое видео в торрентах, но мы парни честные, пиратством не балуемся, да к тому же кино там лежит все больше англоязычное, без локализации. Третий способ - наш! - это купить лицензионный DVD и перегнать его в формат, признаваемый Sony PSP. Я перепробовал немало соответствующих утилит, но остановился на XviD4PSP, которую делает наш парень. Имени его не знаю, но ему нравится называть себя Винни.

Так вот всем хороша программа, но она... бесплатная. Казалось бы, чего тут возмущаться? Это же хорошо, когда денег не просят! Так-то оно так, но в октябре прошлого года Винни увлекся созданием другой утилиты, Winnydows Commander, а XviD4PSP обновлять перестал. Что случилось в октябре читатели этого блога знать должны. Нет, серьезно должны. ДОЛЖНЫ. Что, правда не помните? Гм. Гм. Ладно, оставим кокетство. В октябре появились компьютеры на самой прогрессивной и быстрой платформе в мире - Intel Nehalem. Зело возрадовался я этому факту, кинулся жать видел на термоядерной скорости, и вдруг получил на выходе нечто страшное и для просмотра непригодное. Сунулся разбираться, и обнаружил, что последняя версия XviD4PSP с Nehalem попросту не работает. Пришлось откатываться назад, на позапрошлую инкарнацию, но она и жмет не так качественно, и файлы получаются немного длиннее... В общем, насладиться прелестями Nehalem'а в полном объеме у меня не получается до сих пор, и от печали великой жму видео на самосборном NAS'е, руладами о котором я тут надоел почище, чем PSP.

И что прикажете делать? Написать доброму парню Винни - дорабатывай, лентяй, свое детище под Nehalem? Так он мое письмо просто проигнорирует, прикинув, что ради какого-то техноманьяка добывать Core i7 и докапываться, в чем там косяк, дорого и бессмысленно. Это не умозрительное предположение - я ему писал Будь это продукт коммерческий, шансов докричаться имелось бы побольше - мол, кровные уплочены, давайте пошевеливайтесь. С нашими парнями, правда, это тоже не очень работает (вспомним чудесный почтовый клиент The Bat!, до сих пор думающий, что процессоры бывают только одноядерными), но хоть кричать можно с чистой совестью.

В связи с этим у меня возник странный вопрос. Есть такое понятие - свободный софт. То есть собираются умные добрые парни, пишут гениальные программы (и даже целые операционные системы), а потом отдают свои шедевры всем желающим задаром. Разве что с указанием кошелька вебманей, куда при некотором желании можно перевести пару долларов. Допустим, я на это предложение с радостью отозвался, убедился, что здесь и сейчас все работает просто изумительно, и сделал на бесплатную программу серьезную ставку. Например, возвел в ранг семейной традиции субботний просмотр новой серии мультфильма "Робоцып" на PSP. Или сделал из компьютера музыкальную студию, использующую исключительно свободный софт.

Все работает, все счастливы, и вдруг в компьютере появляется новая железка. Или рождается новый и очень удачный музыкальный формат. Мы идем на сайт к добрым парням, и обнаруживаем, что они уже давно забросили мирские дела и ушли жить в монастырь кармелиток, что в Хайфе. Семейная традиция рушится (хорошо, если одна, без семьи), звукооператор уходит в глубокий запой после недели безуспешных попыток разобраться в новых софтинах для студии, а вы чешете затылок и думаете - зачем была нужна такая вот свобода?

В связи со всем вышесказанным у меня вопрос. Можно ли в долгосрочной перспективе доверять свободному-свободному софту? Не просто свободному, которые делают серьезные компании, расчитывая со временем компенсировать затраты на разработку с консультаций и эксклюзивных патчей. А именно свободному-свободному, создаваемому энтузиастами-одиночками? Есть ли примеры серьезных и постоянно необходимых программ, развиваемых абсолютно безвозмездно, скажем, лет десять? Мне в голову приходит разве что RivaTuner, да и да, пожалуй, не относится к числу жизненно-необходимых... Да, и еще, если можно, давайте не будем развивать тему "там же код обычно открытый, можно самому докрутить, если что". Программисту это действительно не очень сложно. Но не все (к сожалению?) ими становятся.

Я же хочу на выходных попробовать пожать видео для iPhone. Некоторые ценители говорят, что на нем смотрится даже приятнее, чем на PSP. Ох уж эти макоманьяки...

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

Взял я тут "практически" навскидку один 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!

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

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

Sizeof() как раз и существует для определения размерности типа/переменной, в итоге (опущу разные размерности на разных архитектурах) имеет что то типа

sizeof(int): 4
sizeof(float): 4
sizeof(double): 8
sizeof(char): 1

Регистры процессора тоже - 16bit (2 байта) - как AX, BX, CX, DX и тд,

32 - EAX, EBX, ECX, EDX и тд,

64 - RAX, RBX, RCX, RDX и тд,

Все хорошо, если бы только это.

Набор команд SSE (Streaming SIMD Extensions) вносит новый тип размерности, определеный самим железом - 128 бит (16 байт) - XMM0 - XMM7 (8-15)

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

Вот это и называеться векторизацией. SSE появился в Pentium III линейки Intel что говорит что те или иные версии SSE уже в большинстве используемых компьютеров.

Приятно отметить что компиляторы C/C++ (GCC, Intel Compiler) понимают необходимость векторизации и вполне могут помочь в ее использовании.

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

Как очень неплохое начало для GCC - рекомендую посмотреть на опцию -ftree-vectorize  и дальше много интерестного о текущем положении дел и истории например вот тут 

http://gcc.gnu.org/projects/tree-ssa/vectorization.html

Intel Compiler содержит очень достойную инфу в helpах, где разбираеться большое количество примером автоматической векторизации а так же "помощи" компилятору.

Например можно использовать ключевые слова restrict или же #pragma ivdep.

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

например ivdep говорит мол - игнорирую те зависимости что ты (компилятор) себе вычислил/придумал.

 Немного о зависимостях между данными и итерациями в циклах: в основном выделяют

FLOW (READ after WRITE), OUTPUT (WRITE after WRITE) or ANTI (WRITE after READ) - думаю много понятно уже из кратких аннотаций.

Например FLOW

   for (int j=1; j<1024; j++) 

    A[j]=A[j-1];

если использовать /Qvec-report:3 для Intel Compiler или -ftree-vectorizer-verbose=5 для GCC можно узнать в деталях об успехах или неудачах автоматической векторизации  

например так

Intel Compiler:

sample.cpp(11) : (col. 6) remark: loop was not vectorized: not inner loop.
sample.cpp(12) : (col. 5) remark: vector dependence: assumed FLOW dependence between c line 13 and b line 13.

GCC:
vect-1.c:94: note: not vectorized: possible dependence between data-refs a[i_283] and a[i_48]

В срезе векторизации надо отметить что существует для типа SSE инструкций - Scalar (одно действие над даннами) и Packed (несколько действий на разными данными ) например умножение - MUL или в срезе SSE: MULPS (Multiply packed single precision), MULSS  (Multiply scalar single precision). Т.е. например MULPS делает умножение над 4-мя (128 бит / (32 бита на элемент) ) операндами сразу. Что интерестно - время исполнения MULPS vs MULSS  одинаковое для последних процессоров = 1 такт. Информацию о тактах легко найти например в Intel 64 and IA-32 Architectures Optimization Reference Manual.

AVX - следующих шаг, после SSE, вводит в обиход вообще новый тип данных шириной 256 бит , те в два раза шире чем у SSE. Кстати много достойной информации, включая технические детали, компилятор и эмулятор доступно на

http://software.intel.com/sites/avx/ 

 Теперь вы и сами можете оценить оптимизацию доступную простым использованием векторизации.

 Кстати - рекомендую так же посмотреть на свободно распространяемые помощник по SSE/AVX инструкциям и интриксисам - Intel Intrinsic Guide (на странице http://software.intel.com/sites/avx/ )

Разумеется, я далек от осуждения действий AOL - если компании угодно угробить купленный за бешеные бабки проект, она имеет на то полное право. Просто мы, когда писали статью для "Компьютерры", так и не смогли найти примеров откровенного слива рынка хозяином популярной технологии. Например, вы представляете, чтобы файлы формата .psd альтернативный редактор обрабатывал лучше Photoshop? Или чтобы по "родному" Skype приличные люди говорили только под угрозой нанесения ущерба физиономии?

Если у вас в коллекции есть такие "альтернативные" примеры - поделитесь, пожалуйста. Судя по всему, к теме "аськи" нам, IT-журналистам, в ближайшие месяцы придется обращаться еще не раз и не два.

А пока с удовольствием рапортую о публикации на портале "Компьютерра-Онлайн" статьи о моем путешествии в Израиль и визите в центр разработок Intel, расположенный в городе Хайфа. Мне редко нравятся свои статьи, но эта реально удалась. Только попробуйте не согласиться

n = 1000000000
62    h   = 1.0 / (double) n;
63    sum = 0.0;
64
65    for (i = 1; i <= n; i++)
66    {
67           x = h * ((double)i - 0.5);
68           sum +=(4.0 / (1.0 + x*x));
69    }
70
71    mypi = h * sum;

изначально все строилось для MPI , правда захотелось перенести на OpenMP

казалось бы все просто:

 53 #pragma omp parallel for reduction(+: sum)
 54 for (int i = 1; i <= n; i++)
 55    {
 56
 57       x = h * ((double)i - 0.5);
 58       sum +=(4.0 / (1.0 + x*x));
 59    }

(гусары - молчать , пока что ... ).

(компилируем как gcc ./pim.c -o ./pim -O3 -fopenmp -mfpmath=sse)

Практически все (окромя точности, но об этом позже) устраивает и почти красиво, пример Thread Profiler for Linux:

tprofile_cl ./pim
Building project
Instrumenting
 16% pim             ( API Imports ):..

Running:  /mpi/pi/pi/pim

n = 1000000000
Num threads before = 1
myid: 1 i: 0: 0 c:0
mypi: 3.1415926535898211

Application finished

Intel(R) Thread Profiler  3.1  Summary Report
application:          /mpi/pi/pi/pim
collection:           Wed Jan  7 17:52:15 2009
runtime:              3.43215s
# of processors:      4
# of threads:         4
# of waits:           3
wait frequency:       0.874088
average concurrency:  3.96682
Concurrency:
   0 [..........] 0%      0
   1 [..........] 0.913%  0.0301119
   2 [..........] 0.0051% 0.000168224
   3 [..........] 0.349%  0.0114959
   4 [##########] 98.7%   3.25637

Паралельность просто фантастическая!

однако сюрпризы только начинаються если присмотреться подольше и поближе ,

вот пример нескольких последовательных, и не только, запусков:

[maxd@fc9i pi]$ time ./pim
n = 1000000000
mypi:   3.1415926535898211

real    0m3.345s
user    0m13.125s
sys     0m0.032s
[maxd@fc9i pi]$ time ./pim
n = 1000000000
mypi:   3.1415926535898211
real 0m55.433s
user 3m38.935s
sys 0m0.033s

В итоге - иногда время работы ~3 сек и очень часто - ~55 сек - крута, 18х slowdown. Что то мы не подкрутили!

посмотрим поглубже и видим что то типа

  400710:       f2 0f 2a c0             cvtsi2sd %eax,%xmm0
  400714:       83 c0 01                add    $0x1,%eax
  400717:       66 0f 28 ea             movapd %xmm2,%xmm5
  40071b:       39 c2                   cmp    %eax,%edx
  40071d:       f2 0f 5c c4             subsd  %xmm4,%xmm0
  400721:       f2 41 0f 59 44 24 08    mulsd  0x8(%r12),%xmm0
  400728:       f2 41 0f 11 44 24 10    movsd  %xmm0,0x10(%r12)
  40072f:       f2 0f 59 c0             mulsd  %xmm0,%xmm0
  400733:       f2 0f 58 c3             addsd  %xmm3,%xmm0
  400737:       f2 0f 5e e8             divsd  %xmm0,%xmm5
  40073b:       f2 0f 58 cd             addsd  %xmm5,%xmm1
  40073f:       7d cf                   jge    400710 <main.omp_fn.0+0x70>

(btw AT&T синтаксис вовсе не дурен)

запустив VTune/PTU увидим впечатляющий CPI (циклов на инструкцию) ~ 45 при желаемом -как можно ближе к 0.25 но меньше 1 уже хорошо . Кстати - саму ошибку уже видно с разных сторон. Для разнообразия запустим Thread Checker for Linux и уже наглядно видим что то типа

 tcheck_cl ./pim
Intel(R) Thread Checker 3.1 command line instrumentation driver (26185)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Instrumenting
 16% pim             ( All Functions ):..

Running:  /mpi/pi/pi/pim

n = 1000000000
Num threads before = 1
myid:   1       i:      0: 0    c:0
mypi:   3.1415926535898211

Application finished

_______________________________________________________________________________
|ID|Short De|Seve|C|Contex|Description                        |1st Acc|2nd Acc|
|  |scriptio|rity|o|t[Best|                                   |ess[Bes|ess[Bes|
|  |n       |Name|u|]     |                                   |t]     |t]     |
|  |        |    |n|      |                                   |       |       |
|  |        |    |t|      |                                   |       |       |
_______________________________________________________________________________
....

|3 |Write ->|Erro|2|[pim, |Memory write at [pim, 0x728]       |[pim,  |[pim,  |
|  |Write da|r   |1|0x6a0]|conflicts with a prior memory write|0x728] |0x728] |
|  |ta-race |    |4|      |at [pim, 0x728] (output dependence)|       |       |
|  |        |    |8|      |                                   |       |       |
|  |        |    |7|      |                                   |       |       |
|  |        |    |6|      |                                   |       |       |
|  |        |    |1|      |                                   |       |       |
|  |        |    |1|      |                                   |       |       |
 ....

(форматирование несколько "поехало") - кстати Thread Checker оказался самым быстрым способом борьбы.

Тут даже придумано красивое название - False Sharing: несколько потоков мешают друг другу работая с одним ресурсом. Как другой вариан объяснения - читайте blog недавно были интересные блоги насчет красивых и иногда жизненых примеров для общих проблем.

На четырех ядерной машинке 18х ухудшения - интересно.

Как вылечить ? Например так :

 55 #pragma omp parallel for private(x) reduction(+: sum)
 56 for (i = 1; i <= n; i++)
 57    {
 58       x = h * ((double)i - 0.5);
 59       sum +=(4.0 / (1.0 + x*x));
 60    }

добавленое - выделено.

Кстати - исходный код был С где declaration для переменной x было вне цикла, как можно было сделать для С++ и тогда проблемы не было бы вообще.

в итоге наш цикл превращаеться в более простую конструкцию типа:

  400710:       f2 0f 2a c0             cvtsi2sd %eax,%xmm0
  400714:       83 c0 01                add    $0x1,%eax
  400717:       66 0f 28 f3             movapd %xmm3,%xmm6
  40071b:       39 c2                   cmp    %eax,%edx
  40071d:       f2 0f 5c c5             subsd  %xmm5,%xmm0
  400721:       f2 0f 59 c2             mulsd  %xmm2,%xmm0
  400725:       f2 0f 59 c0             mulsd  %xmm0,%xmm0
  400729:       f2 0f 58 c4             addsd  %xmm4,%xmm0
  40072d:       f2 0f 5e f0             divsd  %xmm0,%xmm6
  400731:       f2 0f 58 ce             addsd  %xmm6,%xmm1
  400735:       7d d9                   jge    400710 <main.omp_fn.0+0x70>

которая выполняеться и быстрее и стабильнее.

Насчет точности:

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

например для использования SSE можно попробывать использовать

gcc ./pim.c -o ./pim -O3 -fopenmp -mfpmath=sse

для FPU:

gcc ./pim.c -o ./pim -O3 -fopenmp -mfpmath=387

результаты будут разные:

sse: 3.1415926535898211
387: 3.1415926535897936
org: 3.14159265358979323846
где org - просто Pi взятое из какой либо википедии, кстати FPU более точнее но об этом я уже как то писал.

Время работы FPU кстати неплохое

sse: real 0m3.280s

fpu: real    0m3.894s

Присутствующая векторизация в gcc для этого цикла не сработала и пришлось бы менять код.

Intel Compiler сделал вещи шустрее (используя packed arguments instead of scalar ~ векторизация , loop unrolling etc )  и с уже приведенным C кодом :

icc ./pim.c -O3 -xSSSE3 -openmp -vec-report5 -o ./pim.icc

и результат неплох

real    0m1.857s
user    0m6.528s
sys     0m0.033s

За сим прощаюсь с успехом поздравив Вас в удачной оптимизации

Теперь, когда все позади, хотелось бы выразить недоумение по поводу самой идеи домашних NAS в ее нынешнем воплощении. У меня стоял, пожалуй, лучший из доступных на рынке вариантов. 500-мегагерцовый процессор, 256 мегабайт ОЗУ, гигабитный Ethernet-контроллер, Linux с человеческим лицом - казалось бы, все должно работать, как надо. Ан нет! Максимальная скорость скачивания торрентов не превышала 250 Кбайт/с, хотя Интернет-канала с лихвой хватает на четыре с лишним сотни. Скорость отдачи вообще не превышала 20 Кбайт/с. Банальное копирование файлов с компьютера на NAS загружало минимум половину (!) вычислительной мощи процессора, а если копировать напрямую на внешний накопитель по USB, загрузка составляла всю сотню процентов. Причем скорость скачивания по USB составляла 6 (шесть) мегабайт в секунду, то есть медленнее, чем по 100-мегабитному Ethernet. Как такое возможно - не понимаю.

Ну и не стоит забывать о проблеме шума. Посадив винчестеры и кулер на резиновые прокладки, я таки сделал коробочку пригодной для домашнего использования, но почему в Qnap-то на них сэкономили? Ведь, при всем уважении, себестоимость TS-209 Pro II в разы меньше пяти сотен баксов, которые за него просят.

Чтобы не быть голословным, публикую смету своей альтернативы NAS'ам.

1) Материнская плата Intel Little Falls 2 DG945CLF2 с напаянным Atom 330 (2 ядра) - $85

2) Корпус Morex Cubid 2600RSB (его пример есть, к примеру, тут: http://dont.ru/Morex-Cubid-2600RSB-P/n:-106304.id3595.html) - $103

3) Две "глушилки" для пропеллеров, чтобы не крутились слишком быстро - $5.

4) Двухгигабайтный модуль Samsung DDR2 - $18 (хотя тут я перестраховался, для наших задач достаточно одного гига, так что минус $6)

Итого железо нам обходится в $205. Терабайтный винчестер - еще примерно $125. К сожалению, в моей модели корпуса только одно посадочное место для 3.5-дюймовых версий, но ничто не мешает поставить по соседству еще один ноутбучный (до 500 гигабайт) или прицепить снаружи USB-накопитель любой емкости.

Конечно, есть еще тонкий момент с операционной системой, которая не всегда бесплатна. Самое удобное - поставить Windows XP Pro и управлять малышом при помощи встроенного удаленного рабочего стола. Но это еще и недешево: XP Pro в наших краях продают по $150. Можно ограничиться XP Home и каким-нибудь бесплатным аналогом RAdmin'а, коих развелось изрядно. А для серьезных парней существует уйма бесплатных дистрибутивов Linux, которые, уверен, тоже позволяют настроить удаленное управление системой. Лично я поставил XP Pro, и сейчас жду, пока по почте придет пробная версия Windows Home Server, которая, по слухам, идеально подходит для моих задач. Приятно, что дистрибутив с трехмесячным Trial'ом можно заказать на сервере Microsoft совершенно бесплатно.

А о том, как я на двухъядерном Atom'е жму видео для PSP, расскажу в следующий раз