Performance Aware Programming

[Finalspace]

Ich wollte mal wissen ob Ihr Peformance-Aware entwickelt - sprich Code produziert welcher "Waste" vermeidet, Cachefreundlich ist und die CPU effizient nutzt, z.b. mit SIMD/Vektorisierung.

Die Rede ist dabei aber nicht von Hardcore-Optimierungen, wie man es früher gemacht hat um jedes Bit zu sparen - sondern wirklich nur, wie löse ich mein Problem effizient, mit wenig Code und mit so wenig Balast wie nur möglich.

 

[Aduasen]

Ich denke, es kommt immer darauf an, WAS man entwickelt.
Als ich damals (80er) Informatik studiert habe, war es extrem wichtig, ressourcenschonend zu entwickeln.
Schlicht und einfach auf Grund von Limitierungen bei Speicher und CPU Leistung.
Inzwischen ist es meistens irrelevant - je nach Anwendungsgebiet.

 

[Kalsarikännit]

habe Punkt 2 gewählt, der bestimmte Grund lautet in der Regel "muss schnell fertig werden". Allerdings entwickeln wir auch keine Performance-kritischen Anwendungen.

 

[Martinipi]

Mein "Hello World" hat zumindest noch nie einen PC zum einknicken gebracht.

 

[SaschaHa]

Ich bin als Quereinsteiger in den Bereich Android-App-Entwicklung übergegangen. Dort setze ich vorzugsweise auf (optimierte) Systemfunktionen, um proprietären "Ballast" weitestgehend zu vermeiden, und versuche mit teilweise komplexen Hierarchien so effizient und zugleich konsistent wie möglich zu programmieren. Da ein Hauptteil des Codes eher die grafische Oberfläche sowie ein paar rudimentäre Datenbanken und weniger irgendwelche mathematischen oder performancekritischen Algorithmen betrifft, sind so Dinge wie SIMD und Vektorisierung hier eher nebensächlich.

 

[Tornhoof]

Die Auswahlmöglichkeiten sind etwas beschränkt.

Da fehlt etwas zwischen 1 und 2, nämlich ja, kenne ich und nutze ich dort wo der Profiler sagt es bringt was...

 

[Limmbo]

Wie schon erwähnt fehlen die Anwendungsgebiete. Wir entwickeln vor allem im embedded Bereich und da ist der Speicher meist nur ein Parameter von vielen, den man im Auge behalten muss.

 

[KitKat::new()]

Hier ein Beispiel wie so mancher Codestyle auf wirklich große Performance Unterschiede hinausläuft: https://news.ycombinator.com/item?id=34966137#34974790

Inzwischen ist es meistens irrelevant - je nach Anwendungsgebiet.

Meistens irrelevant für den Entwickler, aber am Ende kaufen Leute doch neue HW, weil Software zu träge wird oder der Arbeitsspeicher ausgeht

 

[Aduasen]

Meistens irrelevant für den Entwickler, aber am Ende kaufen Leute doch neue HW, weil Software zu träge wird oder der Arbeitsspeicher ausgeht

Oder eben die Kunden des Anbieters bei diesem selbst (bei BtB).
Deswegen ist das teilweise gar nicht (mehr) gewollt.

 

[gymfan]

Meistens irrelevant für den Entwickler, aber am Ende kaufen Leute doch neue HW, weil Software zu träge wird oder der Arbeitsspeicher ausgeht

Da geht die recht unspezifische Frage halt schon los. Sind hier nur Antworten von professionellen Entwicklern gewünscht, die ihre SW verkaufen?

Privat wird da optimiert, wo es mir entweder etwas bringt (vor allem auf die vorhandene HW, ich kann einen i9-9900K + 64 GB Ram leider immer noch nicht in mein Tablet einbauen). Also müssen die Teile der Bildverwaltung+Bearbeitung, die ich mobil nutze, auch performant auf dem i3-6100U + 4GB Ram laufen (oder ganz früher auf dem Atom-Netbook).

Und beruflich blieb die Produktions-HW auch über Jahre identisch, womit auch dort, wo es nötig und möglich war, entsprechend die SW optimiert wurde.

Die Rede ist dabei aber nicht von Hardcore-Optimierungen, wie man es früher gemacht hat um jedes Bit zu sparen

Das kommt erst demnächst wieder, wenn ich mir mal wieder Zeit für meine Retro-Computer Projekte nehme.

- sondern wirklich nur, wie löse ich mein Problem effizient, mit wenig Code und mit so wenig Balast wie nur möglich.

Das eine schließt bei mir meist das andere aus. Wenn ich eine (ext.) Library nutze, die intern mit SIMD und co. optimiert ist, dann wird meine SW zwar performanter, trägt aber mehr Ballast mit sich herum wie bei der einfachen Nutzung der .NET Funktionen.

 

[Enurian]

Antwortmöglichkeit fehlt:
Performance ist ein Faktor und muss ab und an optimiert werden, aber high-level und nicht für irgendwelche Caches. Parallelisierung, effiziente DB-Abfragen, Rechenzeit sparen usw. passt ja alles in keine deiner Antworten.

 

[KitKat::new()]

aber high-level und nicht für irgendwelche Caches. Parallelisierung, effiziente DB-Abfragen, Rechenzeit sparen usw. passt ja alles in keine deiner Antworten.

caches und das andere schließt sich nicht aus, sh. meinen Link oben

Man kann z.B. Daten und Logik trennen (data oriented programming) oder Daten und Logik in Klassen(hierarchien) organisieren (object oriented programming).
Ersteres ist nicht nur besser für caches (und spart dadurch Rechenzeit ohne low level Optimierung), sondern auch einfacher parallelisierbar und ggf. optimierbar, obwohl man nur ein High Level Konzept nutzt.

 

[Piktogramm]

Hier ein Beispiel wie so mancher Codestyle auf wirklich große Performance Unterschiede hinausläuft: https://news.ycombinator.com/item?id=34966137#34974790

Ohje.. Wenn ich Beispiele baue, die etwas zeigen sollen bekomme ich meist auch das gewünschte Ergebnis heraus.
Das Clean Code Beispiel dient zur Veranschaulichung eines sauberen, gut wartbaren Stils. Damit dieses Beispiel nicht unnötig aufgebläht wird, gibt es da entsprechend viel Overhead bei der Strukturierung des Programms bei gleichzeitig minimalem Rechenaufwand (Flächenberechnung, also maximal drei 32bit Floats als Multiplikatoren). Derjenige der zeigt, dass man Flächenberechnung viel effizienter gestalten kann tut dies aus absolutem Unverständnis heraus, oder will es absichtlich falsch darstellen.

Ansonsten bin ich maßlos enttäuscht. Wenn er einmal anfängt die Berechnung von Flächen zu vektorisieren hätte er auch gleich in VHDL eine Logik entwerfen können, die extrem effizient und extrem nebenläufig Dreifachmultiplikation von 32bit Floats ausführt. Selbst auf einem kleinen Latice iCE sollten sich da aller >0,01 Takte eine Flächenberechnung realisieren lassen.. Stümper -.-

 

[KitKat::new()]

Wenn ich Beispiele baue, die etwas zeigen sollen bekomme ich meist auch das gewünschte Ergebnis heraus.

Eben nicht:

In order to construct what I would consider the most favorable case for a “clean” code implementation of something, I used existing example code contained in “clean” code literature. This way, I am not making anything up, I’m just assessing “clean” code advocates’ rules using the example code they give to illustrate those rules.

If you look at “clean” code examples, you'll often see an example like this:

 

[Piktogramm]

@KitKat::new()
Das kann der Autor so schreiben, dass es irgendwie "most favorable case" ist. Aber in welcher Beziehung? Als leicht verständliches Beispiel von CleanCode? Da ist das Beispiel wirklich vorteilhaft. Als Beispiel für performante Flächenberechnung, zu dem der Autor es macht ist es ganz sicher kein gutes Beispiel. Das wird hoffentlich Niemand behaupten der Programmieren in Ausbildung, Studium oder mit etwas Anspruch Zuhause gelernt hat[1].



[1] Jaja ist mir auch klar, dass die Schiere Menge an meisem Code, die Diskussion auf ycombinator und auch hier etwas anderes anzeigt.. Lasst mich in meiner heilen Welt

 

[KitKat::new()]

Das kann der Autor so schreiben, dass es irgendwie "most favorable case" ist. Aber in welcher Beziehung? Als leicht verständliches Beispiel von CleanCode?

Bezogen darauf, dass man keinen seltenen edge case im Clean Code Bereich hat, würde ich sagen.
Aber das ist jetzt relativ irrelevant im Bezug von meinem Post, in dem ich nur beitragen wollte, dass Programmierstile sich erheblich auf Performance auswirken können.

Ich selbst würde Clean Code gar nicht ausschließlich mit OOP in Verbindung bringen, auch wenn selbiges in dem Bereich aus historischen Gründen stark vertreten ist.

Das wird hoffentlich Niemand behaupten der Programmieren in Ausbildung, Studium oder mit etwas Anspruch Zuhause gelernt hat[1].

Im Studium ist Performance hauptsächlich Laufzeitkomplexität ;-)

 

[Piktogramm]

[...]dass Programmierstile sich erheblich auf Performance auswirken können.

Wer Mist verzapft verzapft Mist.. Das ist keine bahnbrechende Erkenntnis
Wer computelastige Probleme dadurch beackert jedes Datenfragment als Objekt abzubileden hat den Schuss nicht gehört. Wer dynamische Businesslogik mit Switch-Case und/oder Vektorisierung versucht zu behandeln ist aber genauso ein Depp.

Im Studium ist Performance hauptsächlich Laufzeitkomplexität ;-)

Im Studium ist es Glücksspiel wie welcher Prof. im Rahmen der "Freiheit von Forschung und Lehre" Inhalte vermittelt werden. Da würde ich nicht pauschalisieren, das ist Glücksspiel wer was wie intensiv (oder überhaupt) hatte .
Mit etwas Glück hat man aber 1-2 Kurse Softwareengineering und bekommt verklickert, dass es mehrere Zielkonflikte und viele (faule) Kompromisse gibt.

 

[BeBur]

Hier ein Beispiel wie so mancher Codestyle auf wirklich große Performance Unterschiede hinausläuft: https://news.ycombinator.com/item?id=34966137#34974790

Dann lies mal auch die kommentare dazu. Das Video selbst hatte ich zufällig letztens schon gesehen und ich stimme den beiden obersten Kommentatoren (mabbo und yashabp) zu.

Bitte nicht Performance-Aware entwickeln, sondern Maintenance-Aware. Es gibt im Allgemeinen nur ein Performance Problem, wenn man komplexe Zwischenlayer einsetzt (z.B. Electron oder React Native). Hingegen gibt es überall und andauernd ein Problem mit Bugs, reproducible builds und verwandtem.

 

[KitKat::new()]

Wer Mist verzapft verzapft Mist.. Das ist keine bahnbrechende Erkenntnis

Ich denke nicht, dass das im Allgemeinen als "Mist verzapfen" angesehen wird, sondern es eher in die Richtung von @BeBur geht, dass es einem grundsätzlich egal sein kann, wenn man nicht in speziellen Bereichen arbeitet.

Wer dynamische Businesslogik mit Switch-Case und/oder Vektorisierung versucht zu behandeln ist aber genauso ein Depp.

was verstehst du unter dynamischer Businesslogik?

 

[Piktogramm]

was verstehst du unter dynamischer Businesslogik?

Alles was Geschäftslogik betrifft
Typische Umgebungen von Firmen, wo einfach vorher bekannt ist, dass der Code stetiger Entwicklung unterliegen wird. Weil sich die rechtliche Lage ändert, weil Prozesse falsch erfasst wurden, sich ändern, falsch implementiert wurden, stetig neue Anforderungen hinzukommen, und auch die Entwickler·innen wechseln werden, etc. pp..
An solchen Stellen sollte man Warbarkeit und Erweiterbarkeit bzw. die Prinzipien von "Clean Code" nicht ohne (akute) Not einer Performanceoptimierung opfern.