DSA — алгоритм для создания и проверки электронной подписи с использованием открытого ключа, основанный на вычислительной сложности взятия логарифмов в конечных полях.

Алгоритмы, использующие «большие числа» — всегда хорошие кандидаты на распараллеливание. Дело в том, что даже при современной мощности процессоров многие задачи являются довольно сложными с вычислительной точки зрения. Хотя криптографические алгоритмы, как правило, очень тяжело поддаются распараллеливанию (например, когда значение, вычисленное на предыдущем шаге алгоритма, используется на текущем шаге), чисто математические задачи все же дают определённый простор для распараллеливания.

В данной статье рассмотрим возможность распараллеливания алгоритма DSA.

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

Алгоритмы работают не с исходным сообщением, а с его цифровым дайджестом, сгенерированным при помощи хэш-функции H(x).
Алгоритмы используют следующие параметры:

• простое число q, размерность которого в битах совпадает с размерностью значений, генерируемых хэш-функцией;
• простое число p, такое, что (p-1) mod q = 0. Размерность данного числа задаёт криптостойкость системы и должна быть не менее 1024 бит;
• число g, такое, что его мультипликативный порядок по модулю p равен q (g = h^(p-1)/q mod p, 1<h<p-1, g ≠ 1);
• закрытый ключ x — число в интервале (0; q);
• открытый ключ y, y = g^x mod p.

Подпись (r, s) сообщения H генерируется следующим образом:

1. Выбор случайного числа k из диапазона (0; q).
2. Вычисление r = (g^k mod p) mod q.
3. Вычисление s = (k⁻¹(H + xr)) mod q.
4. В маловероятном случае, когда r или s равны нулю, переход к шагу 1.

Проверка подписи (r, s) сообщения H осуществляется следующим образом:

1. Вычисление w = s⁻¹ mod q.
2. Вычисление u₁ = Hw mod q.
3. Вычисление u₂ = rw mod q.
4. Вычисление v = ((g^u₁y^u₂) mod p) mod q
5. Если v = r, то подпись верна.

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

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

В этом случае для распараллеливания необходимо найти выражения, которые могут быть вычислены независимо друг от друга. Например, для алгоритма генерации подписи это будут вычисление r и k⁻¹ mod q, для алгоритма проверки подписи можно распараллелить два блока (которые будут выполняться последовательно):

1. Вычисление u₁ и u₂.
2. Вычисление g^u₁ mod p и y^u₂ mod p.

А в алгоритме генерации ключей распараллелить можно только генерацию простых чисел (два простых числа будут вычислены со скоростью одного).

Теперь переходим к программной реализации (для простоты я использовал генератор псевдослучайных чисел GMP, который не является криптографически безопасным):

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

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

Если целевая платформа является многопроцессорной (или многоядерной, что в данном контексте одно и то же), а код программы допускает возможность организации параллельных вычислений, то правильное использование OpenMP практически всегда приведёт к росту производительности приложения.

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

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

Организация OpenMP в GCC/Linux

Активация поддержки OpenMP в компиляторе GCC включается путём использования ключа -fopenmp (заметим, что этот ключ должен указываться как при компиляции программы, так и при связывании). Цена использования OpenMP — зависимость от двух динамических библиотек: libpthread и libgomp. Собственно реализация OpenMP находится в библиотеке libgomp; для параллельной обработки используются POSIX-потоки.

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

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

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

• создание мьютекса, барьера и семафора, а также вызов malloc() для выделения памяти под внутренние структуры данных (функция new_team()). В зависимости от поддержки TLS может понадобиться вызов pthread_getspecific();
• создаётся барьер (синхронизационный примитив) для пула потоков (при вхождении в самый первый параллельный регион);
• создаётся требуемое количество потоков; потоки (если система поддерживает данную операцию) могут быть привязаны к конкретному процессору;
• путём вызова pthread_create() создаётся необходимое количество потоков;
• каждый из созданных потоков создаёт семафор;
• производится внутренняя синхронизация потоков, после чего, собственно, и начинаются вычисления.

Отметим несколько особенностей, характерных для libgomp:

• если количество создаваемых потоков оставляется на усмотрение библиотеки времени выполнения, то, например, при наличии четырёх процессоров нет гарантии, что система создаст три потока (один — главный — уже есть, это основная программа): количество создаваемых потоков определяется как разность между доступными процессорами и средней загрузкой за последние 15 минут;
• для того, чтобы библиотека времени выполнения осуществила привязку созданных потоков к конкретным процессорам, наличия в системе функции pthread_setaffinity_np() не является достаточным условием — по умолчанию созданные потоки будут привязаны ко всем доступным процессорам. Это очень легко проверяется:
  #define _GNU_SOURCE 1
  #include <unistd.h>
  #include <stdio.h>
  #include <sched.h>
  #include <omp.h>
  
  int main(int argc, char** argv)
  {
      #pragma omp parallel
      {
          cpu_set_t mask;
          int i;
          sched_getaffinity(0, sizeof(mask), &mask);
          for (i=0; i<CPU_SETSIZE; ++i) {
              if (CPU_ISSET(i, &mask)) {
                  printf("Thread %d: CPU %d\n", omp_get_thread_num(), i);
              }
          }
      }
  
      return 0;
  }

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

  Thread 0: CPU 0                                        
  Thread 0: CPU 1                                        
  Thread 0: CPU 2                                        
  Thread 0: CPU 3                                        
  Thread 1: CPU 0                                        
  Thread 1: CPU 1
  Thread 1: CPU 2
  Thread 1: CPU 3
  Thread 3: CPU 0
  Thread 3: CPU 1
  Thread 3: CPU 2
  Thread 3: CPU 3
  Thread 2: CPU 0
  Thread 2: CPU 1
  Thread 2: CPU 2
  Thread 2: CPU 3
  Для того, чтобы привязать потоки к конкретному процессору, нужно правильно задать переменную среды GOMP_CPU_AFFINITY.

В Linux вся синхронизация потоков в OpenMP основана на фьютексах (это отдельная тема для разговора) и атомарных инструкциях синхронизации процессора, что позволяет снизить накладные расходы. Тем не менее, создание и запуск потока являются относительно дорогими операциями.

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

Иными словами, компилятору приходится создавать дополнительную функцию (в нашем примере это parallel.omp_fn.0). Как следствие, тратится процессорное время на организацию вызовов процедур, сохранение/восстановление регистров и т.п. Сама "параллельная" функция (в случае статического планирования) вызывает omp_get_num_threads() и omp_get_thread_num() для определения количества итераций, которые она должна выполнить.

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

Методика эксперимента

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

Процесс поиска начинается со ста итераций и идёт с переменным шагом: Δ=100 при 100≤i<1000; Δ=1,000 при 1,000≤i<10,000; Δ=10,000 при 10,000≤i<100,000; Δ=100,000 при 100,000≤i<10,000,000.

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

Результаты эксперимента

Эксперимент проводился на процессоре AMD Phenom(tm) II X4 940 Processor, позволяющем программно изменять частоту каждого из ядер, на частотах 800 MHz, 1.8 GHz, 2.3 GHz и 3 GHz. Размер блока, обрабатываемого за одну итерацию, составляет 8 байт.

Данные эксперимента (text/csv, 23,688 байт)
Данные эксперимента (application/vnd.oasis.opendocument.text, 2.5 МиБ)

Используемые обозначения:

S/f

последовательное выполнение алгоритма, частота процессора f ГГц;

P/n/f

параллельное выполнение алгоритма с использованием n потоков, частота ядер процессора f ГГц.

Рисунок 1 — Результаты эксперимента при частоте 800 МГц	Рисунок 2 — Результаты эксперимента при частоте 1.8 ГГц
Рисунок 3 — Результаты эксперимента при частоте 2.3 ГГц	Рисунок 4 — Результаты эксперимента при частоте 3 ГГц

Анализ результатов

Сразу отметим, что данные, полученные в ходе эксперимента, являются весьма приблизительными: очень трудно учесть влияние других процессов, обработку прерываний и прочие вещи, характерные для многозадачных систем; кроме того, использование функции gettimeofday() для измерения промежутка времени ограничивает точность измерений до 1 мс.

В ходе проведения эксперимента были получены весьма интересные (и даже парадоксальные) результаты. В частности, при понижении тактовой частоты процессора с 3 ГГц до 2.3 или 0.8 ГГц получалось, что четыре потока работают быстрее, чем три (что, в принципе, логично), но медленнее, чем два. Парадоксальный, но вполне воспроизводимый факт.

Отметим некоторые факты:

• создание четырёх потоков произошло довольно быстро — в пределах точности gettimeofday() (Википедия приводит пример, что на создание 100,000 потоков уходит порядка 2 секунд на IA-32);
• затраты на поддержание потоков нелинейны: по предварительным результатам получается, что если стоимость поддержания одного потока составляет N единиц, то для двух потоков стоимость будет равна примерно 2N, а для трёх — примерно 2.5N (N не зависит от количества итераций). Очень интересно проверить результаты на восьмипроцессорной системе;
• при произвольно большом количестве процессоров производительность системы с памятью, разделяемой всеми процессорами, ограничена сверху пропускной способностью памяти. Особенно хорошо это видно из данных, полученных для частоты 800 МГц: максимальная производительность алгоритма достигается при использовании всего двух потоков; добавление новых потоков не улучшает ситуацию;
• производительность приложения OpenMP очень сильно зависит от загрузки системы: в случае большого количества активных процессов, затраты на переключение между ними сводят на нет преимущества OpenMP. Отсутствие общесистемной библиотеки, координирующей все потоки OpenMP, может привести к тому, что запуск нескольких приложений OpenMP может привести к большому потреблению системных ресурсов;
• при проектировании высокопроизводительного приложения OpenMP очень важно понимать, как работает кэш процессора. Неправильный подход к работе с данными может привести к неэффективному использованию процессорных кэшей и, как следствие, вынудить процессор тратить полезное время не на вычисления, а на относительно медленные обращения к памяти. Перед проектированием подобных приложений очень неплохо ознакомиться, например, с такими публикациями, как "Programming for tomorrow's high speed processors, today" и "Understanding CPU Caches" Ульриха Дреппера.

Рекомендации

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

• количество потоков по возможности не должно превышать количество доступных процессоров, ибо один процессор (одно ядро) не в состоянии выполнить две задачи параллельно;
• максимальное количество потоков (если не ограничено сверху количеством доступных процессоров) можно приблизительно рассчитать отношением средней скорости копирования блоков данных требуемого размера в памяти к средней скорости работы распараллеливаемого алгоритма. Например, если скорость копирования восьмибайтных блоков составляет 9.6 ГиБ/сек, то например, при скорости алгоритма в 5 ГиБ/сек не имеет смысла создавать более двух (возможно, трёх) потоков. Тем не менее, стоит помнить, что даже если скорость памяти позволяет увеличить скорость передачи данных в два раза, добавление еще одного вычислителя может не привести к реальному ускорению работы в два раза;
• так как производительность приложения OpenMP зависит от загрузки системы, не стоит без необходимости явно указывать количество потоков: в идеале, планировщик операционной системы знает лучше;
• примерное количество итераций, с которого распараллеливание имеет смысл, эмпирически можно оценить при помощи следующего выражения:

  L/(v×n)+c < L/v,

  где L — объём обрабатываемых данных, v — скорость их обработки, n — поправочный коэффициент (равный произведению количества вычислителей на процентный объём распараллеливаемых вычислений), c — время, необходимое на внутреннюю организацию потоков.
  В общем случае коэффициент n является системно-зависимым.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

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

Использование OpenMP должно приводить к увеличению производительности за счет того, что программа (по крайней мере, её параллельные участки) выполняется не на одном процессоре, а на всех доступных. Процесс распределения потоков по процессорам можно контролировать.

В соответствии с законом Амдаля–Уэра (увеличение количества вычислителей приводит к ограничению роста производительности), имея четыре процессора, мы не получим четырёхкратное увеличение производительности. К тому же затраты на синхронизацию и управление потоками сказываются на производительности не лучшим образом. Да и увеличение вычислительной мощности в N раз не приводит к аналогичному росту скорости обращения к памяти.

Я решил проверить, каким будет прирост производительности параллельного шифрования в режиме ECB у алгоритма шифрования ГОСТ 28147—89 на четырёхядерном процессоре.

Операция зашифрования по ГОСТ 28147—89 сама по себе не может быть распараллелена (да и есть ли смысл?). Но так как в режиме ECB операция зашифрования одного блока не зависит от остальных блоков, то процесс можно распараллелить.

Цикл зашифрования выглядит следующим образом (для краткости я не привожу вспомогательные таблицы):

Зашифрование в режиме ECB выглядит так:

Длина явно приводится к знаковому типу для облегчения переноса на OpenMP (в спецификации есть требование, чтобы счетчики циклов были знаковыми).

Параллельная версия процедуры зашифрования будет выглядеть так:

Makefile:

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

Получились весьма интересные результаты:

Параллельная версия алгоритма не только не даёт прироста в производительности, но еще и проигрывает последовательной версии!

Так бы и считал, если бы во время тестирования альтернативной версии не заметил, что параллельная версия выполняется быстрее. Мораль: читайте маны.

Дело в том, что время измерялось следующим образом:

Но CLOCKS_PER_SEC не учитывает, что у нас четыре ядра, а не одно. Или как раз-таки учитывает. И вообще хз. Я так понял, что на выходе я получаю время, которое понадобилось бы процессору на выполнение задачи, если бы он был один. Тёмный лес.

UPD: POSIX requires that CLOCKS_PER_SEC equals 1000000 independent of the actual resolution.

Как правильно:

Итак, что получилось на четырёх ядрах:

Что характерно, в случае с одним процессором оба способа измерения времени работают примерно одинаково, так что будем считать, что в статье "Практическая польза fast-типов" я не сильно наврал со скоростью.

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

Тогда я написал такую процедуру зашифрования, рассчитанную на четыре ядра:

Идея в том, что если потоки выполняются с примерно одинаковой скоростью, возможно улучшить локальность данных в кэше процессора (код, скорее, представлял proof of concept, ибо не учитывает целый ряд факторов).

Результат с использованием секций получился чуть-чуть хуже.

Выигрыш в производительности на четырёх ядрах составил 380% — не так уж и плохо (особенно если считать, что основной целью статьи было показать, что параллельность — это не всегда хорошо).

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Специалисты Intel рекомендуют задавать маску соответствия процессоров (известную как CPU affinity mask) для потоков OpenMP, чтобы привязать поток к определённому процессору (или ядру процессора, что в данном случае одно и то же). Как утверждается, это позволяет минимизировать миграцию потоков и снизить стоимость переключения контекста между процессорами.

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

Wikipedia приводит пример кода для Windows, для Linux я ничего подобного не нашел.

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

Это соответствует такому коду для Windows:

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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