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

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

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

Микроархитектура P5. Короткий конвейер, первый X86 суперскаляр. In-order (U/V конвейеры, pairing rules). Грабли - очень дорогие операции умножения и деления, предсказатель переходов сходит с ума от 2 бранчей подряд. Как и 486, внутри - RISC процессор. Поэтому до 486 при оптимизации старались сократить число команд в коде. Теперь приходилось сокращать число микроопераций. Последний процессор, где оптимизировать количество инструкций почти так же полезно, как работу с кэшем.

Микроархитектура P6. Конвейер все длиннее и длиннее, суперскаляр все шире, мегагерц все больше.  Изменился static branch bredictor, и если производительность зависела от его поведения в P5 - это грабли. Что-то еще важное было, вспомню - дополню.

Микроархитектура NetBurst. Запомнилась людям длиннейшим конвейером, гонкой гигагерц и Trace Cache. Главные эпохальнейшие мегаграбли - 64k aliasing, плавно переходящий, к счастью, в 1M aliasing и наконец 4M aliasing. Кстати, видел у клиента последний раз всего 2 года назад. Неправильное предсказание бранча в критичном цикле тоже могло обозначать грабли, особенно в P4E.

Core 2. Instruction fetch & predecoding. Грабли - производительность первых стадий конвейера. Если в коде много длинных инструкций - это плохо, совсем как в 486 и P5. Еще грабли - L1 cache line split load.

Nehalem. Идеальный процессор, никаких граблей. (// FIXME AK: дополнить этот абзац, когда выйдет Sandy bridge. Объявить его, в свою очередь, идеальным процессором)

Все многоядерный процессоры: грабли - False sharing. К счастью, не очень сложно обнаружить, и просто исправить.

Этот ключик называется PGO - Profile Guided Optimization. Он существенно усложняет процесс компиляции - при его использовании компилировать проект придется 2 раза. Первый раз - для создания продукта, инструментированного специальным кодом, собирающим статистику, необходимую для улучшения производительности. Второй раз - собственно для создания бинарника. В промежутке между этими двумя сборками, требуется запустить бинарник/библиотеку, собранную при первой компиляции, под типичной нагрузкой. В результате бранчи станут лучше предсказываться, функции правильно инлайнится, кэш и регистры - эффективнее использоваться, и т.д.

Звучит сложно. Человек, отвечающий за Sotware Configuration Management/Build scripts, будет рад дополнительной работе . К счастью, это все достаточно делать лишь для Release Candidate сборок.

Зачем вообще городить этот огород? Вот зачем. Я показывал, как пользоваться PGO уже многим клиентам, на примере десятков приложений (штук 20 минимум). И я еще ни разу не наблюдал прироста производительности меньше 10%. Можно сказать, совершенно нахаляву - то есть почти даром. Достаточно один раз переписать build scripts.

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

Знакомьтесь : постоянная производительности PGO - 1.1111111111111 Если у вас получается на реальном приложении (не micro-benchmark), сильно меньше или сильно больше 10%, дайте знать, пожалуйста

И, кстати, Profile Guided Optimization поддерживается не только компилятором Intel, а всеми основными компиляторами. Правда, в разном объеме. Даже в JVM, например, в Harmony JIT есть нечто подобное.

И вот, партия сказала : надо. Надо показать как можно больше попугаев в задаче X. Комсомол ответил : есть. Все как полагается.  Начать следует с выбора железа. Так как можно выбирать любую машинку,  сразу же напрашивается идея взять последнюю модель Xeon 7xxx серии или даже 9xxx, добавить 128 гигабайт оперативки, и попугаи бенчмарка будут довольны. Как раз тот случай, о котором говорят, что у любой сложной проблемы есть простое, очевидное и неправильное решение.

Правильное решение - это сначала погонять программку под Intel Vtune, Intel Performace Tuning Utility. Понять, что и насколько ей важно для производительности - частота ядра, размер кэша второго уровня, третьего, DTLB, пропускная способность памяти, latency. При этом нет особенной необходимости тестировать на всем доступном зоопарке. Обычно достаточно сделать кучу измерений на обычной, но достаточно мощной машинке - вроде рабочей станции на Xeon X5570 с 16 гигами оперативки у меня под рабочим столом.

Turbo Boost очень пригодится в любом случае. 266 добавочных мегагерц лишними не будут. Если программа очень любит memory latency, тогда лучший выбор - последняя модель односокетного Xeon, например W3570 (естественно, с правильно подобранной частотой памяти). Если важен быстрый L1 Cache - X5492. Если большой L2 кэш, доступный одному процессу - тоже X5492. Большой L3 кэш - E7440 или хотя бы X5570.

Ну а уже на самом подходящем для задачи железе можно дальше увеличивать количество попугаев - играть с настройками ОС, Intel compiler, приложением.

И напоследок свежий анекдот о микроархитектуре CPU. Только что коллега-немец рассказал, что недавно видел попытку перевести термин "Out of Order Engine" на немецкий язык. Получилось - "капут машина"

Итак, снова немножко об оптимизации.

Недавно для клиента надо было улучшить производительность одного редкого алгоритма шифрования... Если бы клиент пользовался AES, можно было бы с [почти] чистой совестью посоветовать дождаться Westmere, где есть аппаратная поддержка его ускорения, и посоветовать использовать библиотеку, которая использует соответствующие инструкции. Если бы это был какой-нибудь популярный алгоритм, можно было бы посоветовать IPP - вряд ли бы удалось сделать быстрее, к тому же стоит недорого, не надо платить royalty, и автоматически появляется поддержка всех новых процессоров.

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

В алгоритме шифруются блоки из 64 бит, причем происходит много битовых операция внутри 16 битных слов. Первое дело при анализе производительности блочного алгоритма шифрования - проверить, имеет ли смысл использовать bit slicing. Очень удобно, что в процессоре есть 128 битные SSE регистры, и быстрые операции с ними.

Суть bit slicing в том, что можно взять 128 64-битных блоков, транспонировать в 64 128-битных регистра. Тогда в первом SSE регистре будут только первые битики 128 блоков, во втором - вторые, и т.д. Кстати, ключ/ключи тоже лучше транспонировать. После транспонирования, дорогие битовые операции над 16-битными словами внутри блока становятся дешевыми переименованиями регистров, причем каждая операция сразу влияет на все 128 блоков. Правда, дешевые S-box меняются на цепочку логическких операций. После шифрования, результат приходится транспонировать обратно.

Немного напоминает по идеологии преобразования Лапласа, не так ли ? Результат зависит от протокола, у меня получилось ускорение в 7 раз.

Но что, если 128 блоков подряд найти нельзя? например, если шифруется TCP/IP сессия, и 128 блоков - заведомо больше окна? Тогда может помочь вторая идея - software pipelining. Можно попытаться все действия совершать сразу над 2 словами - одно из одного блока, и одно (аналогичное) из следующего. За счет уменьшения CPI (мера эффективности эксплуатации параллелизмы на уровне микроопераций конвейером) можно тоже получить прирост производительности. У меня получился на 30%.

А ведь еще есть интересные возможности о замене части операций loookup-ами по большим таблицам. (память дешевая, кэш большой, есть software prefetches). Вот где раздолье любителям порассчитывать циклы CPU и латентности кэшей!

Happy hacking!

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% коллег со мной не согласятся: Будущее очень отдаленное, и то вряд ли.

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

Но недавно я услышал от одного клиента совсем другую причину отключения второго ядра. "Мы считаем", говорил архитектор, "что у нас есть несколько не пойманных data-race'ов. Требования к надежности софта очень серьезные, поэтому мы отключим второе ядро в BIOS." Речь идет о встроенном ПО, управляющим ответственной системой, которой пользуются опосредованно все читатели этого блога. Кстати, работает софт под Windows XP. Конечно я оветил: "позвольте, но вы рекомендуете клиентам использовать P4 с Hyperthreading, так что основные data-race'ы должны были уже проявиться в ваших тестах. Плюс ваш софт написан на С++, и Thread Checker'ом их все можно поймать очень быстро"

Так вот, о чем это я: Hyper Threading на P4 - был гениальным нововведеним, которое для хорошо написанного софта не создавало ничего, кроме проблем с отладкой. Зато те многопоточные рограммы, которые еще тогда, 5 лет назад, стабильно работали на P4 с неотключенным HT (а многие - отключали), теперь спокойно и без дополнительной отладки работают на core 2 duo. Тем же, кто поленился тестироваться с HT - придется теперь это делать все равно. Или просить пользователя отключать второе ядро, но на это пойдет только самоубийца, или производитель встроенного ПО.

Я вообще интересуюсь развитием ИИ, но редко (никогда в моем опыте) используются эти технологии в индустриальном программировании. И вот, один клиент разрабатывает интересную систему, позволяющую избавиться от кошмара поддержки древнего app server'a, написанного, скажем, на COBOL'е. 

Как это работает? Сначала "Очень Умный Аналитик" составляет Onthology. На вход системы, базу данных и ее выход ставится сниффер. Результаты, вместе с онтологией, скармливаются "Очень Умному ИИ".  Он пытается все понять, и, естественно, не может.  Задает огромное количество вопросов "Очень Умному Аналитику". Потом успокаивается, и производит код, способный имитировать первоначальную систему.

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

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

Вообще, намечается очередное увлечение Domain Specific Languages (как в 70-80 все производители Больших Телефоных Свитчей писали свой Pascal, ( а выжил только Erlang) ). В этой системе он тоже есть (описание онтологии и общение с аналитиком в ее терминах).

В следующем посте: О различных системах распараллеливания существующих программ. (к сожалению, пока все они "заточены" на узкий класс приложений, в-основном HPC ( за исключением разве что Azul, но и оно имеет узкую нишу))

Но так ли нужно понимание этих нетривиальных деталей, если приложение, например, перестает масштабироваться после добавления более 4 потоков? Часто все оказывается намного проще. Например, зимой я работал с серверным приложением, которое очень хорошо масштабировалось до 6 потоков, но при дальнейшем их увеличении производительность серьезно падала.

Intel Thread Profiler не помог выяснить проблему. Потоки были практически независимы. Микроархитектурных узких мест, описанных в статье выше, обнаружить не удалось. Дальнейший анализ при помощи Vtune показал, что серьезно возрастает время, проведенное в gettimeoftheday. В этой функции ядра вроде-бы и нет вызовов объектов синхронизации. К счастью, можно было не особенно вникать в детали реализации gettimeoftheday. Была возможность вызывать ее на порядок реже, увеличив число потоков до 8 (именно столько ядер в типовом современном двухпроцессорном сервере).

Не люблю рекламу пива Клинское, но приходится признать, что в некоторых вещах действительно сперва обойтись без понтов. (См. мой опыт с Thread Profiler и попытки отыскать низкоуровневые задержки.)

Удачной отладки!

Однако новые возможности процессоров могут оказаться полезными и для приложений первого типа.Если 1-2 ядра из 4-16 приложению достаточно, то запустив несколько виртуальных машин с похожими приложениями, можно использовать вычислительные ресурсы более эффективно. Надежному разделению ОС помогает аппаратная поддержка виртуализации - VT, технология, которую Intel впервые выпустил на рынок еще в конце 2005-го.

 Недавняя статья на WorseThenFailure напомнила мне разговор об end-of-epoch-bug. Мы беседовали за пивом с архитектором одной системы, созданной в 70-е, как и Unix, с которой он любит ее сравнивать. Она почти так же распространена, но гораздо менее известна. К сожалению, я не могу ее здесь назвать. Счетчик времени в этой ОС переполнится в 2104 году, а баги по типу описанного по ссылке выше начнут проявляться несколько раньше.Код ядра системы давно никто не трогал, она пережила 5 процессорных архитектур, и сейчас работает в виртуальной машине в виртуальной машине, исполняющейся на платформе Intel. Вполне эффективно работает, лишь бы не трогать громадный старый отлаженный код на языке, который уже мало кто помнит.

И вот наступает 2104 год... В 2038 году будет достаточно людей, которые понимают, почему "тот сервер, замурованный в углу в 2020'м году, в котором где-то глубоко находится RHEL3, выполняющийся в виртуальной 32-битной машине, стал вдруг глючить". Может быть, даже индустрия появится, по опыту 2000-го. Но до 2104 лично я дожить не надеюсь, хотя я самый молодой инженер из тех, кто знает о проблеме. Конечно, к тому времени системы может и перестать использоваться, или нас вообще завоюют роботы.

Последнее, по-моему, вероятнее.Вот такой недостаток виртуализации, которая вроде-бы всем хороша.