Реалистичное использование ключевого слова C99 'restrict'?


Я просматривал некоторые документы и вопросы/ответы и увидел, что это упоминается. Я прочитал краткое описание, заявив, что это будет в основном обещание от программиста, что указатель не будет использоваться для указания где-то еще.

может ли кто-нибудь предложить некоторые реалистичные случаи, когда его стоит на самом деле использовать это?

2   149   2009-04-14 04:09:53

2 ответа:

restrict говорит, что указатель-это единственное, что обращается к базовому объекту. Это устраняет потенциал для сглаживания указателя, что позволяет лучше оптимизировать компилятор.

например, предположим, что у меня есть машина со специальными инструкциями, которые могут умножать векторы чисел в памяти, и у меня есть следующий код:

void MultiplyArrays(int* dest, int* src1, int* src2, int n)
{
    for(int i = 0; i < n; i++)
    {
        dest[i] = src1[i]*src2[i];
    }
}

компилятор должен правильно обрабатывать if dest,src1 и src2 перекрытие, что означает, что он должен сделать один умножение за один раз, от начала до конца. При наличии restrict, компилятор может оптимизировать этот код с помощью векторных инструкций.

Википедия имеет запись на restrict, С другой пример:здесь.

The Wikipedia пример и очень загораться.

это ясно показывает, как это позволяет сохранить одну инструкцию по сборке.

без ограничения:

void f(int *a, int *b, int *x) {
  *a += *x;
  *b += *x;
}

псевдо сборку:

load R1 ← *x    ; Load the value of x pointer
load R2 ← *a    ; Load the value of a pointer
add R2 += R1    ; Perform Addition
set R2 → *a     ; Update the value of a pointer
; Similarly for b, note that x is loaded twice,
; because a may be equal to x.
load R1 ← *x
load R2 ← *b
add R2 += R1
set R2 → *b

С ограничения:

void fr(int *restrict a, int *restrict b, int *restrict x);

псевдо сборку:

load R1 ← *x
load R2 ← *a
add R2 += R1
set R2 → *a
; Note that x is not reloaded,
; because the compiler knows it is unchanged
; load R1 ← *x
load R2 ← *b
add R2 += R1
set R2 → *b

действительно ли GCC это делает?

GCC 4.8 Linux x86-64:

gcc -g -std=c99 -O0 -c main.c
objdump -S main.o

С -O0, они одинаковы.

С -O3:

void f(int *a, int *b, int *x) {
    *a += *x;
   0:   8b 02                   mov    (%rdx),%eax
   2:   01 07                   add    %eax,(%rdi)
    *b += *x;
   4:   8b 02                   mov    (%rdx),%eax
   6:   01 06                   add    %eax,(%rsi)  

void fr(int *restrict a, int *restrict b, int *restrict x) {
    *a += *x;
  10:   8b 02                   mov    (%rdx),%eax
  12:   01 07                   add    %eax,(%rdi)
    *b += *x;
  14:   01 06                   add    %eax,(%rsi) 

для непосвященных: соглашение о вызове - это:

  • rdi = первый параметр
  • rsi = второго параметра
  • rdx = третий параметр

вывод GCC был еще яснее, чем статья wiki: 4 Инструкции против 3 инструкции.

массивы

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

Рассмотрим пример:

void f(char *restrict p1, char *restrict p2) {
    for (int i = 0; i < 50; i++) {
        p1[i] = 4;
        p2[i] = 9;
    }
}

из-за restrict, умный компилятор (или человек), может оптимизировать это:

memset(p1, 4, 50);
memset(p2, 9, 50);

что потенциально гораздо более эффективно, как это может быть сборка, оптимизированная на достойной реализации libc (например, glibc):лучше ли использовать std::memcpy() или std:: copy() с точки зрения производительности?

действительно ли GCC это делает?

GCC 5.2.1.Linux x86-64 Ubuntu 15.10:

gcc -g -std=c99 -O0 -c main.c
objdump -dr main.o

С -O0, оба одинаковые.

С -O3:

  • С ограничения:

    3f0:   48 85 d2                test   %rdx,%rdx
    3f3:   74 33                   je     428 <fr+0x38>
    3f5:   55                      push   %rbp
    3f6:   53                      push   %rbx
    3f7:   48 89 f5                mov    %rsi,%rbp
    3fa:   be 04 00 00 00          mov    x4,%esi
    3ff:   48 89 d3                mov    %rdx,%rbx
    402:   48 83 ec 08             sub    x8,%rsp
    406:   e8 00 00 00 00          callq  40b <fr+0x1b>
                            407: R_X86_64_PC32      memset-0x4
    40b:   48 83 c4 08             add    x8,%rsp
    40f:   48 89 da                mov    %rbx,%rdx
    412:   48 89 ef                mov    %rbp,%rdi
    415:   5b                      pop    %rbx
    416:   5d                      pop    %rbp
    417:   be 09 00 00 00          mov    x9,%esi
    41c:   e9 00 00 00 00          jmpq   421 <fr+0x31>
                            41d: R_X86_64_PC32      memset-0x4
    421:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)
    428:   f3 c3                   repz retq
    

    два memset вызовов ожидаемый.

  • без ограничения: нет вызовов stdlib, только 16 итераций в ширину развертывание цикла который я не собираюсь здесь воспроизводить :-)

у меня не было терпения, чтобы проверить их, но я считаю, что версия restrict будет быстрее.

C99

давайте посмотрим на стандарт для полноты картины.

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

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

если вызывающий абонент не следует за restrict контракт, неопределенное поведение.

The С99 проект N1256 6.7.3 / 7 "тип квалификаторы" говорит:

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

и 6.7.3.1 "формальное определение ограничения" дает подробности.

строгое сглаживание правило

The restrict ключевое слово влияет только на указатели из совместимых типов (например, два int*) потому что строгие правила сглаживания говорит, что сглаживание несовместимых типов является неопределенным поведением по умолчанию, и поэтому компиляторы могут предположить, что этого не происходит, и оптимизировать.

посмотреть: что такое строгое правило антиалиасинга?

см. также