256-битная векторизация через OpenMP SIMD предотвращает оптимизацию компилятора (скажем, функцию inlining)?

мне отчаянно нужно было решить эту проблему, потому что в моем реальном проекте C, если ни один трюк с шаблоном не использовался для автоматической генерации различных версий функций (просто называемых "версиями"), мне нужно было бы написать в общей сложности 1400 строк кода для 9 разных версий, а не только 200 строк для одного шаблона.

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

я планировал используйте inline функции sum_template для версии. В случае успеха, это происходит во время компиляции, когда компилятор выполняет оптимизацию. Однако ПРАГМА OpenMP оказывается неудачной во время компиляции. Затем можно выполнить управление версиями на этапе предварительной обработки с помощью макрос только.

, чтобы избавиться от inline функции sum_template, Я вручную вставляю его в макрос macro_define_sum:

#include <stdlib.h>

// j can be 0 or 1
#define macro_define_sum(FUN, j)                            \
void FUN (size_t n, double *A, double *c) {                 \
  if (n == 0) return;                                       \
  size_t i;                                                 \
  double *a = A, * b = A + n;                               \
  double c0 = 0.0, c1 = 0.0;                                \
  #pragma omp simd reduction (+: c0, c1) aligned (a, b: 32) \
  for (i = 0; i < n; i++) {                                 \
    c0 += a[i];                                             \
    if (j > 0) c1 += b[i];                                  \
    }                                                       \
  c[0] = c0;                                                \
  if (j > 0) c[1] = c1;                                     \
  }

macro_define_sum(sum_0, 0)
macro_define_sum(sum_1, 1)

в этом макрос-только версии j непосредственно заменяется 0 или 1 at во время расширения макроса. Тогда как в inline функция + макрос подходите в вопросе, у меня только sum_template(0, n, a, b, c) или sum_template(1, n, a, b, c) на стадии предварительной обработки, и j в теле sum_template распространяется только в более позднее время компиляции.

к сожалению, выше макрос дает ошибку. Я не могу определить или протестировать макрос внутри другого (см. 1, 2, 3). ПРАГМА OpenMP, начинающаяся с # вызывает проблему здесь. Поэтому я должен разделить этот шаблон на две части: Часть до прагмы и часть после.

#include <stdlib.h>

#define macro_before_pragma   \
  if (n == 0) return;         \
  size_t i;                   \
  double *a = A, * b = A + n; \
  double c0 = 0.0, c1 = 0.0;

#define macro_after_pragma(j) \
  for (i = 0; i < n; i++) {   \
    c0 += a[i];               \
    if (j > 0) c1 += b[i];    \
    }                         \
  c[0] = c0;                  \
  if (j > 0) c[1] = c1;

void sum_0 (size_t n, double *A, double *c) {
  macro_before_pragma
  #pragma omp simd reduction (+: c0) aligned (a: 32)
  macro_after_pragma(0)
  }

void sum_1 (size_t n, double *A, double *c) {
  macro_before_pragma
  #pragma omp simd reduction (+: c0, c1) aligned (a, b: 32)
  macro_after_pragma(1)
  }

мне давно не нужно macro_define_sum. Я могу определить sum_0 и sum_1 сразу с помощью двух макросов. Я также могу настроить прагму соответствующим образом. Здесь вместо функции шаблона у меня есть шаблоны для блоков кода функции и может использовать их с легкостью.

выходные данные компилятора в этом случае ( проверьте его на Godbolt).

обновление

Спасибо за различные отзывы; все они очень конструктивны (вот почему я люблю переполнение стека).

спасибо Марк Glisse В для меня использование прагмы openmp внутри #define. Да, это было плохо, что я не искал эту проблему. #pragma - это директива, а не реальный макрос, поэтому должен быть какой-то способ поместить его в макрос. Вот аккуратная версия с использованием _Pragma оператор:

/* "neat.c" */
#include <stdlib.h>

// stringizing: https://gcc.gnu.org/onlinedocs/cpp/Stringizing.html
#define str(s) #s

// j can be 0 or 1
#define macro_define_sum(j, alignment)                                   \
void sum_ ## j (size_t n, double *A, double *c) {                        \
  if (n == 0) return;                                                    \
  size_t i;                                                              \
  double *a = A, * b = A + n;                                            \
  double c0 = 0.0, c1 = 0.0;                                             \
  _Pragma(str(omp simd reduction (+: c0, c1) aligned (a, b: alignment))) \
  for (i = 0; i < n; i++) {                                              \
    c0 += a[i];                                                          \
    if (j > 0) c1 += b[i];                                               \
    }                                                                    \
  c[0] = c0;                                                             \
  if (j > 0) c[1] = c1;                                                  \
  }

macro_define_sum(0, 32)
macro_define_sum(1, 32)

другие изменения включают в себя:

• я знак конкатенации создать имя функции;
• alignment является аргументом макроса. Для AVX значение 32 означает хорошее выравнивание, а значение 8 (sizeof(double)) по существу не подразумевает выравнивания. преобразования в строку требуется разберите эти маркеры на строки, которые _Pragma требует.

использовать gcc -E neat.c проверить результат предварительной обработки. Компиляция дает желаемый результат сборки ( проверьте это на Godbolt).

несколько комментариев по Питеру Кордесу информативный ответ

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

-mavx256-split-unaligned-load не является проблемой в моем приложении, потому что я выделю выровненную память и применю заполнение для обеспечения выравнивания. Мне просто нужно пообещать компилятору выравнивания, чтобы он мог генерировать выровненные инструкции загрузки / хранения. Мне нужно сделать некоторую векторизацию на несогласованных данных, но это способствует очень ограниченной части всего вычисления. Даже если я получу штраф за производительность при разделенной несогласованной нагрузке на самом деле не будет замечен. Я также не компилятор каждого файла C с автоматической векторизацией. Я только делаю SIMD, когда операция горячая на кэше L1 (т. е. она привязана к процессору, а не к памяти). Кстати, -mavx256-split-unaligned-load на GCC; что это для других компиляторов?

я осознаю разницу между static inline и inline. Если inline функция доступна только для одного файла, я объявлю его как static так что компилятор не создает его копию.

OpenMP SIMD может сделать уменьшение эффективно даже без GCC ' s -ffast-math. Однако он не использует горизонтальное добавление для агрегирования результатов внутри регистра аккумулятора в конце сокращения; он запускает скалярный цикл для добавления каждого двойного слова (см. блок кода .L5 и .L27 in выход Godbolt).

пропускная способность-хорошая точка (особенно для арифметики с плавающей запятой, которая имеет относительно большой задержка, но высокая пропускная способность). Мой реальный код C, где применяется SIMD, - это тройное гнездо цикла. Я разворачиваю внешние два цикла, чтобы увеличить блок кода в самом внутреннем цикле для повышения пропускной способности. Тогда достаточно векторизации самого внутреннего. С примером игрушки в этом Q & A, где я просто суммирую массив, я могу использовать -funroll-loops спросить GCC для разворачивать петли, используя несколько аккумуляторов для увеличения объема.

на этом Q & A

я думаю, люди будут относиться к этому Q & A более технически, чем я. Они могут быть заинтересованы в использовании атрибутов компилятора или настройке флагов / параметров компилятора для принудительной вставки функций. Поэтому ответ Питера, а также комментарий Марка под ответом по-прежнему очень ценны. Спасибо снова.