You aren't smarter than your compiler!

hustbaer schrieb:

...

Ok, daran habe ich nicht gedacht. Du hast Recht.

hustbaer schrieb:

Man sieht also: es ist wieder mal der Compiler schlauer als der der behauptet schlauer als der Compiler zu sein. Weil der Compiler weiss was er hier zu tun hat, und Code generiert der es auch tut.

Und die beiden anderen, viel einschneidenderen Fälle gekonnt ignoriert, um ein voreiliges Fazit ziehen zu können?

Zeus

Ein Compiler ist nicht vom einem Computer geschrieben sondern von sehr smarten Menschen

Nett von Dir ... Ich schreibe nämlich gerade einen

hustbaer

Blutegel schrieb:

hustbaer schrieb:

Man sieht also: es ist wieder mal der Compiler schlauer als der der behauptet schlauer als der Compiler zu sein. Weil der Compiler weiss was er hier zu tun hat, und Code generiert der es auch tut.

Und die beiden anderen, viel einschneidenderen Fälle gekonnt ignoriert, um ein voreiliges Fazit ziehen zu können?

Kein voreiliges Fazit. Ich beziehe mich auf den einen Fall. Und der demonstriert dass du Beispiele bringst die du nicht verstehst bzw. nicht ausreichend beurteilen kannst (bzw. genauer: zumindest ein solches Beispiel).

Das heisst nicht dass du in den anderen Fällen nicht trotzdem Recht haben kannst - ich treffe darüber einfach keine Aussage. Unter anderem weil ich mir die anderen Fälle nicht genauer angesehen habe.

----

Davon abgesehen: Grundsätzlich stimmt es natürlich dass Compiler oft für equivalenten C++ Code ganz unterschiedlichen Maschinencode generieren - der auch ganz unterschiedlich schnell sein kann. Weil kein Compiler einen allmächtigen Optimizer hat. Dummerweise kann sich das allerdings auch mit jeder Compiler-Version/Revision ändern -- also welche Variante schneller ist. Wenn du Beispiele findest die bei ganz unterschiedlichen Compilern alle gleich ausgehen, dann kann man vermutlich wirklich darauf schliessen dass der eine C++ Code vermutlich leichter zu optimieren ist als der andere. Und ggf. dass ein bestimmtes Feature momentan "nicht gratis" ist, auch wenn es das theoretisch sein sollte bzw. sein könnte.

Wichtig sind allerdings die Schlüsse die man daraus zieht. Und die sollten nicht "ich kann das besser" sein, denn damit kann man schnell gewaltig auf die Nase fliegen. Wenn man allerdings Code hat wo es auf das letzte Bisschen Performance ankommt, dann sollte man Profilen und/oder den generierten Code verschiedener Varianten inspizieren. Bzw. wenn man sehr erfahren und sehr mutig ist, dann kann man auch mal an Stellen die wichtig aber nicht SO wichtig sind was hinschreiben wo man einfach schätzt dass die Performance besser sein wird. Die Erfahrung zeigt aber dass man sich damit eben sehr schnell verschätzt.

Und die Erfahrung zeigt weiters, dass Leuten die über das hier von dir aufgeworfene Thema mit einer bestimmten Ausdrucksweise diskutieren, eher nicht zu den Leuten gehören die das ganze wirklich gut und sachlich beurteilen können.

EOP

Ich hb schon Ende der 80iger den Code von TurboC optimiert. Optimierung ist halt so ein Ding. Entweder man kann es oder eben nicht.
Die ganze Geschichte ist aber schon ca. 30 Jahre her.
Assembler-output ausgeben lassen und dann die Register ändern und ähnliche Geschichten ...

hustbaer

Bloss gut dass sich in den letzten Jahren bei den Optimizern so-gut-wie nichts getan hat.

Blutegel schrieb:

Hallo.

Dieser Spruch ist wahrscheinlich der gefährlichste und unwahrste in der gesamten modernen Programmierung. Er führt dazu, dass man sich nicht mehr viele Gedanken über Low-Level-Zeug macht, sondern dem Compiler blind vertraut. So habe ich auch gedacht, bevor ich mich dann tatsächlich selbst davon hab' überzeugen wollen. Dank Compiler Explorer geht das ja heutzutage ganz einfach.

Wie sich in unzähligen Tests herausgestellt hat, sind auch heutige C++-Compiler immer noch extrem schlecht im Optimieren und händisch ist man da noch immer besser bedient.
Beispiel: 50% mehr Code unter MSVC, wenn man dem Compiler vertraut: https://godbolt.org/g/hZAeza

Auch viele der vermeintlichen Zero-Overhead-Mechanismen aus C++, wie z.B. die neuen std::initializer_list s, kommen zu einem hohen Preis:
https://godbolt.org/g/ROqzNi
https://www.c-plusplus.net/forum/341741

Wie seht ihr das?

Für 99.99% des Codes der täglich geschreiben wird ist das total irrelevant. Bei weit über 50% des Codes ist es sogar egal, ob der beste Algorithmus oder die besten Datenstrukturen verwendet werden. Die Regel, dass 80% der Zeit in 20% des Codes verbraten werden passt relativ gut.

Wenn du in einem Bewerbungsgespräch sagst, dass du schnellen Code gegenüber lesbarem Code bevorzugst, bist du bei den meisten schon raus.

-Emil- 0

Ich interpretiere den Spruch für mich ganz anders und schreibe deswegen meinen Code unter der folgenden Priorisierung :

fail-safe/robust Code
lesbarer Code

--- falls Code zu langsam
3) Optimierung des Algorithmus
*es bringt meist viel mehr, sich die Komplexität des Algorithmus anzuschauen und dort anzusetzen. "binary vs linear search" bringe ich als Beispiel mal an
*
--- falls Code immernoch zu langsam
4) profile --> disassemble --> optimize

In den Schritten 1-3 vertraue ich dem Compiler blind ...
An Punkt 4 bin ich in den letzten Jahren noch nicht angelangt, meist war eher die Wahl des Algorithmus total für die Tonne ...

Columbo

-Emil- schrieb:

An Punkt 4 bin ich in den letzten Jahren noch nicht angelangt, meist war eher die Wahl des Algorithmus total für die Tonne ...

Das sehe ich ähnlich. Optimierung auf Profiler Ebene ist erst notwendig, wenn man die Grenzen seiner Maschine ausloten will. Viele sollten erstmal den Ansatz optimieren, dort kann man ganze Komplexitätsklassen rausholen.

hustbaer

-Emil- schrieb:

[i]es bringt meist viel mehr, sich die Komplexität des Algorithmus anzuschauen und dort anzusetzen. "binary vs linear search" bringe ich als Beispiel mal an

Wobei nicht gesagt ist dass binary immer schneller ist.