Sammelthread zu Visual C++’ Compiler

[Krishty]

Diese Tabelle aus dem neuen Post über NRVO erklärt so einiges – von

„warum ist C-style-Code schneller als C++?“

bis

„Warum ist return { x }; schneller als Foo bar = { x }; return bar;?“ …

Überhaupt ist der ganze Artikel ein Schatz für Low-Level-Optimierer!

[Lord Delvin]

Wieso macht es einen Unterschied ob Datenfluss durch eine benannte Variable geht?

[Schrompf]

Weil's laut C++ dann eine LValue ist, und dann kann's wegen Aliasing oder so nicht mehr so sicher ausgeschlossen werden, dass die irgendwo referenziert wird? Irgendwie so.

[dot]

Weil's dann im Allgemeinen nicht mehr möglich ist, garantiert zu wissen, dass die Copy elided werden kann. Es kann ja beliebig viele Returns geben, die über beliebig komplexen Kontrollfluss erreicht werden können. Und nicht alle diese Returns müssen überhaupt die selbe Variable returnen… siehe auch die Beispiele aus dem C++ Team Blog Post. Klar, man könnte nun bestimmte Situationen spezifizieren, in denen die Sprache NRVO garantieren kann. Das wird aber sehr schnell sehr kompliziert und von fragwürdiger Sinnhaftigkeit…

[Krishty]

Ihr habt beide ein Bisschen Recht und beide ein Bisschen Unrecht. Ja; Lvalue wird der wichtigste Grund sein. (Verschiedene Return-Pfade und -Werte schafft man ja auch mit Rvalues, oder verstehe ich was falsch?) Wahrscheinlich wollten sie gerade so viel spezifizieren, dass gute Compiler und gebildete Entwickler optimalen Code generieren können; aber auch genau so wenig, dass es den Compiler-Entwicklern keine Kopfschmerzen macht. Und dann hat man halt die Low-Hanging Fruit in den Standard genommen, die sowieso schon jeder Compiler auf die eine oder andere Weise für POD implementiert hatte.

[dot]

(Verschiedene Return-Pfade und -Werte schafft man ja auch mit Rvalues, oder verstehe ich was falsch?)

Code: Alles auswählen

X fun()
{
	X x;
	
	if (funfun(&x))
		return X(42);
	
	return x;
}

Was nun? Der Compiler kann x nicht in den Returnslot platzieren weil, im Falle dass das if genommen wird, muss er erst das Returnvalue konstruieren und danach x destroyen (die Konstruktoren und Destruktoren könnten über Seiteneffekte ihre Reihenfolge beobachten). Der Compiler kann gar nicht wissen welcher Pfad überhaupt genommen wird, ohne dass x zuerst konstruiert wurde, die Konstruktion von x kann daher auch nicht je nach Pfad in einem anderen Platz erfolgen. Sofern ich nichts übersehen habe, ist NRVO hier schlicht und einfach unmöglich, zumindest unter der Annahme, dass die Reihenfolge der Aufrufe aller relevanten Funktionen potentiell observable Behavior ist.

Wenn ich mich recht erinnere, gab es vor einiger Zeit ein Proposal, eine Untermenge von NRVO zu standardisieren. Das scheint aber nicht weit gekommen zu sein. Wie gesagt, es wird sehr schnell sehr kompliziert, NRVO über extrem triviale Fälle hinaus zu spezifizieren. Ich bezweifle stark, dass sich das rentiert.

[Krishty]

Super Beispiel; danke!

[Lord Delvin]

Ah danke; was ich natürlich nicht mehr im Blick hatte, war dass man die Scope-based Deallokation in C++ hat, weswegen man im Compiler wohl nicht einfach beschließen kann, dass man eine Lifetime früher beendet, wenn der Wert danach nicht mehr verwendet wird. Ohne das wäre das Beispiel im Prinzip im if "return X(&x, 42)". Und bei dem ganzen Adressnevertaken-trivialdestruktor-Geraffel wird dann Krishtys Argumentation ziehen.

[Krishty]

MSVC Machine-Independent Optimizations in Visual Studio 2022 17.7

Ich hatte schon gemerkt, dass meine Programme besser optimiert wurden – jetzt haben sie dazu endlich eine Erklärung abgegeben.

[Krishty]

Wer hatte hier nochmal die Probleme bei der Optimierung von Byte Swaps? War es dot?

• 17.4 improvements
  • Performance improvements that will help every architecture:
    • Improve bswap for signed integers.

[Krishty]

Ich wunderte mich, dass ich lange nicht mehr die Warnung zu impliziter Konvertierung zu bool gesehen habe … und tatsächlich: Sie ist abgeschaltet worden.

Ihr müsst der Compiler-Befehlszeile /w34800 übergeben, falls ihr sie wieder einschalten wollt.