restrict

hustbaer

Ich verstehe auch nicht ganz wieso der restrict Thread geschlossen wurde.

Ich finde es nicht total beknackt anzunehmen dass jemand ne DLL/Shared-Object/... bauen will, die/das ein paar Funktionen exportiert, die Zeigerparameter gleichen Typs entgegennehmen.
(Bzw. es reicht ja schon wenn einer der Typen char* ist.)

Oder sonst (ohne DLL/SO) so einen Fall hat wo er gerne gute Performance hätte, aber nicht garantieren kann dass der Compiler die Funktion überall inline expandieren wird.

ps: Es soll auch immer noch Leute gegen, die LTCG nicht verwenden, weil die Build-Zeiten bei ihren Projekten dadurch inakzeptabel werden. Und die aus dem selben Grund auch kaum Inline-Implementierungen machen.

SeppJ

hustbaer schrieb:

Ich verstehe auch nicht ganz wieso der restrict Thread geschlossen wurde.

Während das Thema zwar interessant gewesen wäre, war von der Fragestellung her klar, dass der TE keine Diskussion wünschte, sondern Streit. Den Wunsch nach Nicht-Diskussion habe ich ihm dann erfüllt.

hustbaer schrieb:

Ich verstehe auch nicht ganz wieso der restrict Thread geschlossen wurde.

Ich auch nicht. Vielleicht war der erste Satz etwas zu provokativ.

Ja, es ist absichtlich in zwei Dateien, damit die Methode nicht geinlined wird. Bitte beibehalten.

Lol. schließen wir also genau das aus, wovon du genau weißt, dass dies der Grund ist, warum du restrict in C++ nicht brauchst. Künstlich konstruiertes Beispiel.

Ich weiß nicht sicher, was der Grund ist. Ich vermute, das Programm ist so simpel, dass der GCC erkennt, dass sich die Pointer nicht überlappen. Das kann er aber sicher nicht in allen Fällen.

Den Fall, dass irgendeine halbwegs performancekritische Funktion nicht im Header definiert ist, hat man schnell mal. Dass die zwei Referenzen/Pointer auf den gleichen Typ entgegennimmt auch.

Mal ein weiteres Beispiel, wie ein restrict als Bedingung umschrieben wird: http://www.cplusplus.com/reference/algorithm/copy/

The ranges shall not overlap in such a way that result points to an element in the range [first,last). For such cases, see copy_backward.

Das kann der Compiler optimieren, weil er weiß, dass er da restrict annehmen kann (ja, restrict gibt es als Extension und das macht oft einen Unterschied). Und dann gibt es immer noch die C-Funktionen strcpy/memcpy/wctomb/..., die für mehr Performance direkt aufgerufen werden können. restrict wird rege benutzt:

grep restrict stdio.h stdlib.h string.h

gibt mehr als 200 Treffer aus.

Dann hat c++/bits/valarray_array.h 35 mal __restrict__ und das ist ein inline-Header.

Wenn eine allgemeine Diskussion und keine Fallanalyse gewünscht ist, dann ein paar Fragen:

- Wieso brauche ich restrict in C++ weniger/nicht?
- Gibt es Möglichkeiten, restrict nachzubauen, wenn ich es doch mal brauche?

TNA

Ich denke, diese Diskussion kann man für alle "Hinweise" führen die besondere Optimierungsmöglichkeiten erschließen sollen, wie z.B. auch __builtin_expect. Wer solch handoptimierten Code schreiben muss/möchte, wird das wohl eh an die jeweilige Plattform/Compiler angepassten Code schreiben müssen. C++11 bietet mit Attributes zumindest die Möglichkeit, dass die Compilerhersteller de-facto-Standards entwickeln, welche auch allgemein gültiger C++ Code sind.

camper

Restrict++ schrieb:

Mal ein weiteres Beispiel, wie ein restrict als Bedingung umschrieben wird: http://www.cplusplus.com/reference/algorithm/copy/

The ranges shall not overlap in such a way that result points to an element in the range [first,last). For such cases, see copy_backward.

Das kann der Compiler optimieren, weil er weiß, dass er da restrict annehmen kann (ja, restrict gibt es als Extension und das macht oft einen Unterschied).

Das ist allerdings nur bei Skalaren (oder Arrays aus Skalaren) ausreichend. Sobald Klassen im Spiel sind, ist diese Bedingung keineswegs ausreichend um Optimierungen zu erlauben, für die restrict eingeführt wurde - und ich habe auch keine Ahnung wie Compiler restrict in diesem Fall gegenwärtig interpretieren (ich vermute mal, es wird ignoriert).
Soweit ich mich erinnere, wurde restrict deshalb nicht in C++ aufgenommen, weil es zu schwierig war, die Semantik vernünftig zu definieren, und nicht etwa, weil kein Nutzen gesehen wurde. Es müsste sich also nur jemand die Mühe machen und einen entsprechenden Vorschlag beim Standardkomitee einreichen.