Сообщите компилятору С++, что аргумент не имеет псевдонима

Одно из больших различий между C/C++ и Fortran, когда дело доходит до скорости, заключается в том, что первые языки используют указатели, которым можно присваивать псевдонимы, и поэтому компилятору необходимо загружать данные на каждой итерации цикла, в то время как выделяемый Fortran не имеет этой проблемы.

C предлагает ключевое слово restrict, поэтому вы гарантируете компилятору, что указатель не является псевдонимом. Для c++ стандарт не предлагает эту опцию. Я не хочу использовать расширение поставщика, так как меня беспокоит переносимость, но это также важная часть моего приложения. Следовательно, я не буду полагаться на вещи, выходящие за рамки стандарта, когда они имеют основополагающее значение для моего приложения.

ВОПРОС

Мой вопрос заключается в том, есть ли способ гарантировать компилятору С++, что конкретный аргумент указателя не является псевдонимом. Поможет ли ссылка на C++ (т. е. передача ссылок в качестве аргументов по значению невозможна, поскольку мы имеем дело с очень большими массивами)? Или я должен просто написать эти подпрограммы на C и вызывать их из моего приложения на C++?

  void HEAVY_CALC( double *p1, double *p2 , double *p3, int n1)
  {
     
       for(int i = 0; i<n1 ; i ++ ) {
           p1[i] = Func_1( ) ; 
           p2[i] = Func_2( ) ;  
           p3[i]= Func_3( ) ;  
       }
     
  }

Поскольку указатели здесь могут быть обработаны другими, компилятор будет загружать p1,p2,p3 на каждой i итерации. В C, если я добавлю restrict, это будет разрешено. Что произойдет, если я добавлю ссылку вместо указателя, т.е.

    void HEAVY_CALC( double* &p1, double *&p2 , double* &p3, int n1)

Изменит ли это что-нибудь?


person A2LBK    schedule 10.07.2020    source источник
comment
Не могли бы вы показать минимально воспроизводимый пример некоторого кода, который вы пытаетесь оптимизировать?   -  person Alan Birtles    schedule 10.07.2020
comment
Хорошо, я постараюсь показать очень простой пример   -  person A2LBK    schedule 10.07.2020
comment
Аааа, вот почему компиляторы C++ поддерживают ключевое слово __restrict в качестве расширения. Даже на вики написано C++ does not have standard support for restrict, but many compilers have equivalents that usually work in both C++ and C и __restrict is supported by those three compilers. (например, gcc clang msvc)   -  person KamilCuk    schedule 10.07.2020
comment
Да, я знаю это, но идея этого вопроса заключалась в том, есть ли другой способ обеспечить это, не выходя за рамки стандарта.   -  person A2LBK    schedule 10.07.2020
comment
связанные: stackoverflow.com/questions/22724980/   -  person 463035818_is_not_a_number    schedule 10.07.2020


Ответы (1)


[Есть ли] способ [обещать] компилятору [C++], что конкретный аргумент указателя не имеет псевдонима [..], не выходя за рамки стандарта[?]

Нет, нет.

Вместо этого обычно можно использовать нестандартный __restrict, который был представлен в основных цепочках инструментов для точного подключения этот пробел. Переносимость здесь не такая проблема, как вы могли бы подумать, поскольку GCC, Clang и Visual Studio преднамеренно поддерживают одно и то же ключевое слово.

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

person Asteroids With Wings    schedule 10.07.2020
comment
Спасибо. Может ли ссылка на указатель изменить картину проблемы с псевдонимом просто из любопытства? - person A2LBK; 10.07.2020
comment
@ A2LBK Я не понимаю, почему это так. - person Asteroids With Wings; 10.07.2020
comment
__restrict обеспечивает подмножество того, что restrict делает в C. Предположительно, некоторые части функциональности restrict, не предоставляемые __restrict, компиляторам трудно реализовать на C++. - person Peter; 10.07.2020
comment
@Peter Это верно только в VS. Для GCC и Clang __restrict точно такой же, как restrict в C. Не стесняйтесь нажимать на некоторые из ссылок, которые я предоставил для получения дополнительной информации об этой функции. - person Asteroids With Wings; 10.07.2020
comment
Хороший ответ. Забавно, как комитет по стандартам решил, что пользовательские литералы важнее, чем введение restrict. - person Bathsheba; 10.07.2020
comment
@Вирсавия Действительно ???? - person Asteroids With Wings; 10.07.2020
comment
Одна проблема с restrict заключается в том, что способ определения термина, основанного на определении в C99, создает абсурдные, двусмысленные и неработоспособные угловые случаи. Если бы определение указывало транзитив, определенно основанный на отношении, и запрещало бы сглаживание только между указателями, которые определенно основаны на P, и теми, которые определенно основаны на чем-то, что определенно не основано на P, это упростило бы правильную обработку. и многое другое полезное для программистов. - person supercat; 10.07.2020