Предотвращение потери __restrict__ при использовании промежутков GSL

Мне (в основном) нравится новая инициатива основных рекомендаций C++ и то, что предлагает библиотека поддержки рекомендаций. В частности, я хочу больше использовать spans. Однако я столкнулся с проблемой, что __restrict__ не является частью С++, хотя я хочу/должен его использовать.

Чтобы быть более конкретным: без span я бы заявил:

void foo(int* __restrict__ p, size_t len);

Но если я сейчас объявлю:

void foo(gsl::span<int> s);

Я не получаю эффект __restrict__, если мой компилятор не супер-умный. Я мог бы усердно молиться богам gcc/clang/msvc и сказать:

void foo(gsl::span<int> __restrict__ s);

или, в качестве альтернативы, я мог бы настроить реализацию GSL span<T> так, чтобы указатели T* begin и T* end сами были __restrict__ отредактированы. Однако это совсем не уверен, что это будет соблюдено.

Итак, могу ли я как-то заставить __restrict__'ion? Или я должен просто отказаться от него? Это лишает удовольствия переключаться на span's...


person einpoklum    schedule 30.05.2016    source источник
comment
Мое личное мнение: если вы достаточно заботитесь о производительности, чтобы использовать __restrict__ на gsl::span, вы, вероятно, не хотите использовать gsl::span в первую очередь, но сначала я бы убедился, что переключение на span действительно замедляет вашу программу.   -  person MikeMB    schedule 21.02.2017
comment
@MikeMB: Почему ты так говоришь? Это полная противоположность. Мы на C++... Я хочу использовать более высокий уровень абстракции и повысить производительность одновременно... :-) Кроме того, я хочу избежать мой API взрывается с еще большим количеством параметров.   -  person einpoklum    schedule 21.02.2017
comment
@MikeMB: Но позвольте мне спросить вас вот о чем: как насчет внутреннего использования только пары указатель-длина? То есть назначение int* __restrict__ p = s.data(); ?   -  person einpoklum    schedule 21.02.2017
comment
Конечно, это зависит от конкретного варианта использования, платформы, компилятора и т. д., и мое мнение основано на довольно небольшом наборе данных. Тем не менее, мое общее предположение (пока я не определил обратное с помощью тестов) заключается в том, что если вы заботитесь об улучшении производительности на 0-10%, которое может обеспечить __restrict__, накладные расходы, введенные gsl::span, вероятно, будут запрещены. Если вас интересует конкретный фрагмент кода, где __restrict__ позволяет компилятору генерировать значительно более эффективный код, то очень вероятно, что добавленная косвенность нарушит эти оптимизации компилятора.   -  person MikeMB    schedule 21.02.2017
comment
И когда я говорю использовать, я имею в виду фактическое использование диапазона для доступа к данным (через итераторы или оператор индекса), а не просто наличие структуры, которая связывает указатель и длину, которую вы затем снова разделяете   -  person MikeMB    schedule 21.02.2017