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

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

Что я услышал интересного и нового? Новый адаптер беспроводной связи Wi-Fi позволит держать соединение с двумя сетями или устройствами одновременно. Что это дает? Простейший пример - вы сможете находиться в интернете и при этом играть в peer-to-peer игры. Кстати, о peer-to-peer – у нашего стенда стоят два мощных лаптопа, на которых можно поиграть в World of Conflict друг с другом по Wi-FI. Правда именно сейчас у них батарейки сели, но мы их скоро зарядим !

И еще о батарейках. Оказывается, правильно распараллеленная игра дает выигрыш не только в скорости,  но и в энергопотреблении - одно ядро, нагруженное на 100%, потребляет примерно на четверть меньше, чем два по 50. (Надо будет на досуге подумать, почему так получается ).

(more...)

За последнее время мне довелось наблюдать несколько таких попыток, в которых параллельный код был написан при помощи библиотеки Threading Building Blocks (TBB). К удивлению экспериментаторов, их простые параллельные программы порой не только не показывают ускорения по сравнению с обычной, последовательной версией, но даже и проигрывают в скорости! И далеко не всегда автор может (или хочет) разобраться, что к чему.

Разбираться приходилось мне, как одному из разработчиков TBB. А поскольку мне уже не раз предлагали вести сетевой журнал-блог на Intel Software Network, я в конце концов решил попытаться, и начать с анализа таких вот примеров. Они, с одной стороны, просты и понятны: не каждый готов начать параллельные эксперименты со сколь-нибудь сложной программы, а написать цикл, суммирующий элементы вектора – дело недолгое. С другой стороны, они весьма познавательны, причём порой именно в силу простоты.

Начну как раз с суммы элементов вектора. Вопрос о том, почему столь простая программа медленнее в параллельной TBB версии, чем в не-параллельной, возник на форуме TBB (см. тему “performance of parallel_for”). Я приведу здесь лишь часть кода:

#define REAL double
#define MAX 10000000
class SumFoo {
    REAL *a;
    REAL sum;
    ...
    void operator()(const blocked_range<size_t>& r) {
        REAL *arr = a;
        for(size_t i=r.begin(); i!=r.end(); i++) sum+=arr[i];
    }
};
void ParallelSumFoo(REAL a[], size_t n, size_t gs) {
    SumFoo sf(a,n);
    parallel_reduce(blocked_range<size_t>(0,n,gs), sf);
    ...
}
class SerialApplyFoo {
    REAL *a;
    size_t len;
    double sum;
public :
    SerialApplyFoo(REAL *array, size_t length) : a(array), len(length){
        sum = 0.0;
        for(size_t i=0; i<len; i++)
            sum += a[i];
    }
    …
};
int main() {
    task_scheduler_init init;
    REAL *array = new REAL[MAX];
    ...
    SerialApplyFoo sf(array, MAX);
    ParallelSumFoo(array, MAX, GRAINSIZE);
    ...
}

На двухъядерном процессоре Intel® Core® 2 Duo, вместо ожидаемого двукратного ускорения, параллельный код работал почти вдвое медленнее, чем последовательный; на моём ноутбуке, к примеру, 0.08 сек против 0.044. В чём дело?

Прежде всего, давайте посмотрим, а что произойдёт, если параллельный код запустить последовательно, в одном потоке. С TBB это можно сделать двумя способами: либо явно указав количество потоков (в нашем случае, один) конструктору объекта инициализации библиотеки task_scheduler_init, либо установив параллельному алгоритму так называемый «размер зерна» (grain size) равным количеству итераций цикла. Я воспользуюсь первым способом:

    task_scheduler_init init(1);

Результат может показаться неожиданным: 0.21 сек, почти впятеро медленнее, чем исходный последовательный код! Такое замедление явно не из-за использования TBB. Неудивительно, что и на двух ядрах нет выигрыша.

Всё дело в оптимизации, проводимой компилятором. Цикл суммирования в последовательной версии очень прост для оптимизации; компилятор знает о нём всё, начиная от константной длины (передача через аргумент для компилятора не помеха), заканчивая тем, что результат sum должен быть виден только по выходу из конструктора. Поэтому он может сгенерировать очень эффективный машинный код, к примеру, вот такой (я использовал Visual Studio* 2005):

            fldz
            lea      eax, DWORD PTR [edi+010h]
            mov      ecx, 0x2625A0h
main+0x105: fadd     QWORD PTR [eax-16]
            add      eax, 0x20h
            sub      ecx, 0x1h
            fadd     QWORD PTR [eax-40]
            fadd     QWORD PTR [eax-32]
            fadd     QWORD PTR [eax-24]
            jnz      main+0x105

0x2625A0 – это 2500000, четверть длины массива. Компилятор развернул четыре итерации цикла в одну, снизив расходы на обслуживание цикла. Промежуточные результаты вычислений накапливаются в регистре процессора, и только конечный результат будет записан в память. На каждую итерацию исходного цикла ровно одна операция чтения данных из памяти.

В случае использования TBB для компилятора всё не так просто. Начало и конец цикла определяются полями объекта, переданного по ссылке, длина цикла во время компиляции неизвестна, результат накапливается в поле данных “живого” объекта. Компилятор вынужденно более консервативен, и результат не замедлил сказаться:

execute+0x57: fld      QWORD PTR [edi]
              add      ecx, 0x1h
              fadd     QWORD PTR [edx+08h]
              add      edi, 0x8h
              fstp     QWORD PTR [edx+08h]
              cmp      ecx, DWORD PTR [esi+08h]
              jnz      execute+0x57

Здесь одна итерация цикла обрабатывает один элемент, но при этом задействует 3 операции чтения (!) и одну – записи. Помимо элемента данных, каждый раз подгружаются из памяти значение конца цикла для сравнения и промежуточная сумма, которая затем сохраняется и на следующей итерации подгружается снова.

Изложив всё это в форуме, я добавил, что тест «отдаёт предпочтение» последовательному коду, и этим, боюсь, направил автора не в ту сторону. В попытке улучшить тест, автор ввёл чтение размера массива с клавиатуры и заменил в не-параллельном коде объект на функцию:

REAL SerialSum(REAL *a_, unsigned long int start, unsigned long int end) {
    REAL sum = 0.0;
    for(unsigned long int i=start; i<end; i++)
        sum += a_[i];
    return sum;
}

Первое изменение делает тест более реалистичным и несколько усложняет развёртывание цикла; второе никак вообще не влияет, потому что в новой функции промежуточная сумма накапливается в локальной переменной, которая точно так же может храниться в регистре процессора. А чтобы решить проблему, надо в параллельный код внести изменения, которые помогут компилятору применить оптимизацию, а именно – использовать в operator() локальные переменные:

    void operator()(blocked_range<size_t> &r) {
        REAL local_sum = 0;
        const size_t end = r.end();
        for(size_t i=r.begin(); i!=end; i++)
            local_sum+=a[i];
        sum += local_sum;
    }

И вот какой получен машинный код:

              fldz
execute+0x58: fadd        qword ptr [edx]
              add         edx,8
              sub         ecx,1
              jne         execute+58h
              fadd        qword ptr [edi+8]
              fstp        qword ptr [edi+8]

Последние две инструкции – добавление локального результата к полю sum. Как и в последовательном коде, мы получили одно обращение к памяти на итерацию, и это сразу сказалось на скорости: теперь параллельный код выполняется 0.033 сек на двухъядерном процессоре. Ускорение достигнуто, но с коэффициентом 1.33, а не 2. Почему? В этом попробуем разобраться в следующий раз.

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

Вчера мне прислали ссылку на сайт некой компании TIOBE Software, которая занимается консалтингом, и в том числе – анализом кода на предмет его соответствия неким стандартам качества… Впрочем, не это меня заинтересовало.

На их сайте есть рейтинг “популярности” языков программирования, который называется просто и с достоинством – “TIOBE Programming Community Index”. Насколько я понял из описания, данный индекс составляется исходя из статистики поисковых машин, и основывается на “доступности опытных программистов, курсов и поставщиков решений” (конец цитаты).

Первые 10 строк, под картинкой ссылка на полную таблицу.

Не берусь судить о объективности и показательности такого рода данных. Тем не менее, рейтинг исправно и регулярно обновляется, и он заставил меня задуматься…

Во-первых, из 20 “наиболее популярных” языков я когда-либо использовал только 9. Думаю, это нормально :). О четырех языках - SAS, D, Lua и Logo - я вообще не имею никакого представления, что немного меня беспокоит. Причем два из этих четырех языков (Lua и Logo) демонстрируют какой-то невероятный рост популярности. Видимо, я что-то важное в последнее время упустил :).

Что еще интересно – большинство из языков, упомянутых в таблице, имеют средства распараллеливания. Те, где это в принципе возможно :). Используются ли эти средства в реальной жизни? Ситуация с C++, Java и .NET вроде ясна, а вот что с PERL и Python? Вопрос тем, кто пишет на подобных языках - насколько критичны для ваших типовых задач механизмы распараллеливания? И насколько они удобны для вас?

По сумме баллов в трех турах bugman занимает сейчас пятое место, а в целом Россия удерживает пять мест в двадцатке: 5-е, 9-е, 11-е, 13-е и 15-е. Очень неплохо, ведь в конкурсе участвуют программисты из множества стран. Желаю нашим программистам дальнейших успехов: впереди еще 9 этапов и главный приз, который, я надеюсь, приедет в Россию :).

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

Существуют категории программного обеспечения, где производительность оправдывает любые средства, например какая-нибудь сложная математика, [де]кодирование медиа данных и т.п. В данном случае выбор С++ почти очевиден. Интел прилагает серьезные усилия, чтобы помочь разработчикам такого рода софта. В том числе, выпускает компиляторы и библиотеки вроде TBB.

В то же время есть приложения, ориентированные на бизнес – сервера приложений, веб-сервера и прикладные задачи «офисного» класса. И я совершенно согласен с мнением, что таких приложений намного больше. В то же время, намного больше и поставщиков инструментов для задач такого рода. Если взять, к примеру, тот же .Net, то можно упомянуть Parallel FX с TPL, или упомянутый на нашем форуме MC#.

Что делает Интел для разработчиков бизнес-приложений на новых языках, в том числе MRTE? Во-первых, устоявшиеся продукты, такие как библиотеки IPP и профилировщик VTune поддерживают все основные языки. Я сейчас специально проверил, в IPP есть примеры для C# а VTune по-прежнему профилирует .NET и Java приложения. Вероятно, придет время и для относительно новых продуктов, таких как TBB.

С другой стороны, TBB – проект с исходным кодом, и я не вижу никаких проблем использовать все преимущества TBB (включая структуру библиотеки) в любом другом проекте. Например, можно создать сборки для .NET на основе TBB и получится библиотека для нужной вам платформы. Я даже слышал мнение, что многое в том же Parallel FX позаимствовано из TBB.

Однако, вернемся к конкурсу. Если статистика конкурса покажет, что большинство участников предпочитают решения на том же .NET и считает их более элегантными, вопреки дополнительным баллам – думаю, это будет серьезным поводом для ребят из команды TBB задуматься о создании .NET клона. Хотя на этом рынке уже Parallel FX… Короче, тут есть над чем голову поломать…

На мероприятие приехали все 11 наших победителей - из Питера, Киева, Вятки и Нижнего... Лично я был этому приятно удивлен, ведь большинство студентов в наше время успешно совмещает учебу с работой и потратить пару дней на поездки, наверное, было не так уж и просто. Тем приятнее было всех увидеть и со всеми познакомиться!

Марианна Светлосанова награждает победителей

Стив Чейз поздравляет участников конкурса

Андрей Нарайкин с незапланированной официальной речью

Андрей Нарайкин делится секретами оптимизации

А теперь ссылки на архивы с файлами большого размера:

Часть 1 (~3.3Mb)
Часть 2 (~3.6Mb)
Часть 3 (~2.6Mb)

И еще раз спасибо Юле за фотографии!

PS: Если кому-то понадобится еще больший размер - не стесняйтесь, пишите!

Я обещал опубликовать комментарии наших экспертов к дополнительному рейтингу конкурса «Студенческий кубок Intel: оптимизация многопоточных приложений».

Перед тем как перейти к собственно комментариям, мне хотелось бы сказать вот что: мы с жюри конкурса собирались несколько раз, анализировали результаты, думали, спорили и сомневались… И принять окончательное решение было очень непросто, поверьте! Наш специалист по оптимизации Максим Локтюхин компилировал ваши приложения и перепроверял результаты до 2-х ночи, потом мы строили разные рейтинги и читали пояснительные записки, снова собирались, спорили и снова сомневались…

Мы старались быть объективными, насколько это возможно. И наше общее объективное мнение (то, что совпало :), – каждый из участников вложил труд, время и частичку души в эту работу. За это и объявляем вам наш огромный, торжественный, трудовой респект!

Итак, к нашим экспертам. Андрей Нарайкин, Валерий Федорович Курякин и Игорь Ермолаев анализировали работы участников, а я попробовал «скомпилировать» их мнения в данном посте. Подробнее об официальных результатах конкурса я писал в этой статье.

Юрий Мальков продемонстрировал отличное знание микро-архитектуры, понимание и навыки параллельного программирования, видно очень хорошее знание инструментария, умение прилично его использовать и структурированный подход: последовательная оптимизация, параллельная оптимизация, общая.
Юрий сделал анализ алгоритма и предложил улучшения, аргументировав свои предложения. Наконец, нам понравилось описание проекта Юрия – оно очень неплохого качества. Лучшее из всех приведенных.

Александр Романов также показал отличное знание микро-архитектуры и навыки параллельного программирования. Грамотно воспользовался инструментами оптимизации. Проявил дисциплинированность в описании параметров системы. Наконец, из комментариев в коде видно, насколько Александр вложился в анализ производительности и оптимизацию. С технической точки зрения – отлично сработано.

Сравнивая работы Юрия и Александра, эксперты отметили два разных подхода к оптимизации: «университетский» и «политеховский». Александр много экспериментировал. Это, несомненно, плюс, но некоторые решения приняты просто на основе экспериментов («так оказалось быстрее»), хотя выбор был далеко не очевиден. Юрий работал «по системе», структурно. Плюс - составил великолепное описание своей работы. По оценке экспертов Юрий получает высшую оценку, хотя по результатам измерений Александр, несомненно, – лидер. Он же сохраняет и лидерство в общем зачете.

Евгений Калишенко выступил «экономично» (большой +): минимизировал изменения, «бил» в главные проблемные точки. Технически – сделал все на хорошем уровне. Отмечаем хорошее знание инструментария и умение его использовать
Из минусов - экономично выступил и в описании. Краткость она, конечно, сестра таланта, но нам хотелось бы увидеть пояснения, почему сделаны те или иные изменения.

Илья К. Налицо понимание и навыки параллельного программирования, видно очень хорошее знание инструментария. Структурированный подход к работе: последовательная оптимизация, параллельная оптимизация, общая. Неплохое общее описание (сразу видно - литературу хорошую читал ). К сожалению, «что-то пошло не так» - лишь седьмое место по таймингам.

Павел Зубарев и Вера Кононова. Описания – краткие. Изменения кода – логичны, но можно было сделать больше (что собственно лидеры и доказали).

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

Руслан Увашев. Нам понравился подробно прокомментированный код, который прислал Руслан. Из комментариев понятно, что сделано и почему. Руслан всячески старался соблюсти условия корректного выполнения программы… И это, видимо отчасти его подвело – лидеры подошли к проблеме более агрессивно и аргументировали свою позицию, привели разные варианты. Тем не менее, стремление блюсти букву закона мы отмечаем плюсом.

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

Юрий Демин, Евгений Гришуль. Сделанные ребятами изменения очень логичны, но можно было сделать и больше.

Владимир Червяков. Видны приложенные усилия… Но… Конкурс есть конкурс, многие показали лучший результат.

Общий итог дополнительного рейтинга:
Лидер – Юрий Мальков
Второе место – Александр Романов
Третье место - Илья К.
Евгений Калишенко, Павел Зубарев и Вера Кононова – близкие результаты, соответственно 4-е - 6-е места.
И замыкают дополнительный рейтинг Алексей Щербаков, Руслан Увашев, Петр Процик, Юрий Демин – 7-10 места.

Буду рад ответить на вопросы о конкурсе. Вы можете задавать их тут или на форуме.

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

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

Не буду повторять Викторию, которая уже написала в своем посте о неоднородности аудитории и сложности создания одинаково интересного и поездного материала для всех. Хотя этот материал показал очень высокий уровень слушателей! Скажу только, что на будущий год мы подумываем над организации двух дневного семинара для разработчиков, некого мини-аналога IDF. Такой формат позволит нам дифференцировать материал, а также ввести долгожданные «лабораторные работы», т.е. больше времени уделить реальным примерам.

А Вы бы пришли на двухдневный семинар?

Нам важно знать Ваше мнение. Если есть что-то, что вы побоялись оставить в анонимной анкете – напишите нам об этом здесь.

Win threads, PThreads

Программист управляет всем, чем можно. Умелый программист, потратив много сил, получит корректную программу. Потратив еще много сил, получит корректную масштабирующуюся программу. И т.д.

OpenMP

Если вам повезло с задачей (или просто вы пишите курсовую по методом мат. вычислений), то это идеальный способ посчитать все быстро на вашем домашнем Quad Core Extreme Edition CPU Если серьезно, я относился к OpenMP всегда очень скептически, но все чаще начинаю использовать ее для прототипов в самых неожиданных задачах.

Boost Threads

Единственный потенциально 100% портируемый С++ вариант. Больше преимуществ на первый взгляд не заметно.

Ace Threads

Я бы не стал включать в список, но некоторые мои клиенты его успешно используют...

Intel TBB

Здесь должна быть неприкрытая, наглая и лживая реклама Правда, я очень люблю TBB, и считаю ее дизайн просто великолепным. К сожалению, я опасаюсь, что у нас может не получится должным образом ее продвинуть на рынок. (Что хорошо получается с процессорами, не всегда происходит с остальными продуктами). Пожалуйста, обратите внимание на этот продукт - он может существенно облегчить распараллеливание в тех задачах, в которых применим.

Ct

Даже линка нет, настолько секретная. Но Гугл вам в помощь. Может оказаться очень полезной года через 2, а может и нет...

MPI.

Несмотря на то, что MPI используется обычно для HPC задач в кластерах, в последнее время есть тенденция использовать message passing параллелизацию и в многоядерных решениях, в том числе, например, создавая кластера из виртуальных машин.

(pre-MPI)

Экзотические. Я имею в виду не C/C++/Fortran, а Erlang, параллельный Хаскель, и тому подобные. Могут быть страшно эффективны, но как найти команду программистов, с ними справляющихся?

Transactional memory.

Жутко модная вещь, многие считают, что за ней - будущее. Мое личное мнение (просто сугубое ИМХО), 80% коллег со мной не согласятся: Будущее очень отдаленное, и то вряд ли.

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