Neulich in der Kneipe..."Compiler sind die besseren Programmierer"?!

Super das endlich jemand ein Thread dazu aufgemacht hat.

Bin ganz deiner Meinung, es wird kaum noch auf Optimierung geachtet weil die Systeme ja mittlerweile schnell genug sind und das sich nicht lohnt.
Das mag ja vielleicht auch stimmen, besonders wenn man in einer Softwarefirma arbeitet und einem Kunden eine schnelle und vernünftige Lösung präsentieren soll.

Da habe ich vollstes Verständnis das nicht jeder Programmierer versucht den Code noch um +1.5% (etwas unter-/übertrieben) schneller zu machen oder das das Programm am Ende dann nur 125 MB statt 130 MB RAM schluckt.

Wenn es aber um langfristige Berechnungen und schnelle Abarbeitung von Aufgaben gehen soll, bei der die Zeit der Programmierung keine so große Rolle spielt, dann lohnt es sich definitiv mal die paar Extrastunden zu investieren um das Programm doch noch ein Stück zu verbessern.

Ich persönlich versuche immer redundante Zeilen zu vermeiden und nur das nötigste zu erledigen damit ich am Ende nicht sehr viel optimieren muss, weil man beispielsweise für Scripte / Programme die nicht viel können müssen solche Optimierungen absolut nicht notwendig sind.

Nichtsdestotrotz versuche ich bei komplexeren Aufgaben (die nicht in AutoIt geschrieben sind, sondern z.B. in C#) durchaus meine Software zu verbessern, nicht nur damit sie schneller läuft sondern damit ich nebenbei meinen Stil und Programmierart verbessere.

Außerdem ist es ziemlich hübsch anzusehen das das Programm mit ein paar kleinen Änderungen um mehrere Prozent schneller läuft.

Zitat von Andy

dass Compiler heutzutage Code generieren, welcher (von Menschen) nicht mehr weiter zu verbessern ist

Falsche Tatsache. Dies war nicht meine Aussage. Die korrekte Aussage ist unten zu finden.

Zitat von Andy

beliebiger Quellcode

Fehler Nummer eins gefunden: Das war nie Ausgangssituation, geschweige denn Gegenstand der Sache. Es geht um eine große Menge, nicht etwa um "Alle", das würde implizieren dass Aussage 2 natürlich auch so richtig ist.

Zitat von Andy

Anders herum gesagt, ein Mensch in Form eines ASM-Programmierers sei im Vergleich zum Compiler maximal "gleich gut".

Eine Aussage, die ich nicht tätigte.

Zitat von Andy

Compiler hat "automatisch" den besten (nicht von Menschen zu verbessernden) Code erstellt

Ich weiß wirklich nicht woher du diese Aussagen nimmst, bin aber beeindruckt. Da solltest du jemandem mal auf die Finger hauen.

Also dann mal loslegen:
Meine Aussage dazu war, ist und wird bleiben: Wenn du deinen Prozessor kennst, dann produzierst du besseren Code als dein Compiler. Wenn du das nicht tust, dann nicht.
Um der Aussage mal kurz den Interpretationsfreiraum zu nehmen: Jemand der beschissenen Code produziert kann seinen Prozessor selbstverständlich nicht kennen, sonst würde er nicht so töricht sein und beschissenen Code produzieren.

Der Grund dafür liegt im Kern dessen, was dein Prozessor dir beim Pipelining abnehmen kann. Angenommen du schaust dir deinen ASM kompilierten Code an und stellst fest, dass ein paar Anweisungen redundant sind "Hä? Warum schiebt er hier ne Anweisung rein die nichts tut?" dann denkst du dir erstmal "Das kann weg."
Völlig falsch. Das kann eben nicht weg. Du weißt nicht, ob es deiner Pipeline zu Gute kommt, wenn sie einen Takt stallt und dann weiter macht, weil der Compiler bereits erkennt dass sonst ein Hazard auftritt (der mehr Zeit kostet als 1 Takt), oder eben nicht.
Und das, da würde ich fast drauf wetten, können 99% aller Software Entwickler nicht (mich natürlich eingeschlossen).
Dazu mal ein kurzer Beitrag von Heise.de - Compilervergleich: Intel vor Microsoft vor GCC.
Zitat aus dem Artikel: "Verallgemeinert kommt Louel zu dem Ergebnis, dass Intel mit seinem Compiler die Nase vorn hat. Die GCC litten unter anderem daran, dass sich viele ihrer Tuning-Optionen letztlich als unproduktiv erwiesen hätten."
Genau auf diesen Punkt will ich hinaus.

Nächstes Beispiel: Loop Unrolling. Man fässt sich an den Kopf, dass eine Datei "etwas" größer wird, aber im Endeffekt greifen wir der Pipeline unter die Arme weil sie einfach alles abarbeiten kann. Macht dein Compiler je nach Bedarf für Einen, man würde aber eine for-to Schleife nicht n-mal kopieren, nur weil es schneller ist.

Die Frage die sich mir nach den getätigten Aussagen stellt ist, ob hier wirklich einer ernsthafte Absicht einer Diskussion ist. Wenn ja, dann wären 90% der Aussagen im Eingangspost absolut überflüssig, weil sie nichts mit der Aussage per se zu tun haben, sondern eher sind à la "Der Compiler kann aus Scheiße Gold machen". Das ist natürlich kein Gegenstand der Sache, geschweige denn eine Basis auf der man sich unterhalten müsste.

Zitat von alpines

Wenn es aber um langfristige Berechnungen und schnelle Abarbeitung von Aufgaben gehen soll, bei der die Zeit der Programmierung keine so große Rolle spielt, dann lohnt es sich definitiv mal die paar Extrastunden zu investieren um das Programm doch noch ein Stück zu verbessern.

Da würde ich fast das präferieren, was Andy vorschlug: HLL (€: Selbstverständlich in die Richtung, sprich:) Warum dann nicht gleich einen eigenen Prozessor entwerfen (angenommen es geht um wirklich spezielle Aufgaben, z.B. Datenbanken)

Zitat von alpines

redundante Zeilen

Hmm das ist schön und gut.
Redundant wäre sowas:
int i = n;
i += 2;
könnte man sich vermutlich an den Kopf fassen. Zwecks Lesbarkeit ist das aber eindeutig besser als die Alternative (das Beispiel ist nicht gut gewählt, verdeutlicht aber den Sachverhalt). Und der Compiler (der gelebte Antichrist) kürzt das sowieso so zusammen, als stünde da "n + 2".

Zitat von alpines

solche Optimierungen absolut nicht notwendig sind

Und genau das ist eine beschissene Einstellung. "Ob wir das in 5 oder 6 ms erledigen ist doch egal" ist es eben nicht!
Wenn man ein Snippet publiziert und sich nur seine Eigenen Eingaben analysiert hat, dann wird man denken "Ja super läuft schnell". Sicher, für genügend kleine Eingaben macht es keinen Unterschied ob 50 oder 60ms, das spürt man nicht mal.
Dann nutzt aber jemand diese API (oder was auch immer) und stellt fest, dass es Sack langsam ist.
Gerade im OpenSource Bereich stolpert man viel zu oft über Code, wo man am liebsten heulen würde.

Zitat von Andy

Wie programmiert/compiliert ihr? Ist (Code-)Optimierung überflüssig/überbewertet?

Überbewertet nicht, aber mir fehlt das KnowHow um noch weiter zu optimieren.

Zitat von Xorianator

Und genau das ist eine beschissene Einstellung. "Ob wir das in 5 oder 6 ms erledigen ist doch egal" ist es eben nicht!
Wenn man ein Snippet publiziert und sich nur seine Eigenen Eingaben analysiert hat, dann wird man denken "Ja super läuft schnell". Sicher, für genügend kleine Eingaben macht es keinen Unterschied ob 50 oder 60ms, das spürt man nicht mal.
Dann nutzt aber jemand diese API (oder was auch immer) und stellt fest, dass es Sack langsam ist.
Gerade im OpenSource Bereich stolpert man viel zu oft über Code, wo man am liebsten heulen würde.

Jetzt unterschlägst du nämlich was. Ich sagte explizit das es für Scripte und Programme ist die nicht viel tun müssen, beispielsweise einfache HotKey-Bindings oder Notifier o. ä.
Da lohnt es sich absolut nicht, natürlich kann man bis zum Exzess alles rausholen was geht aber das ist bei anderen Projekten wesentlich angebrachter als bei einfachen Sachen.

Ich wollte nicht dich direkt kritisieren , das war ein bisschen ungünstig Diese Einstellung pflegen leider viel zu viele Leute bei tatsächlich "wichtigen" Sachen, die dann hochgeladen werden.

Meine Meinung ist, dass ein Compiler nur so gut ist, wie sein Programmierer und somit schließt sich der Kreis wieder.

Wenn ich ein Programm schreibe und die Exe "schnell" genug arbeitet, dann hat der Compiler seine Arbeit ordentlich erledigt. Für die meisten Fälle trifft das auch zu.
Begibt man sich z.B. in die "brotlose Kunst" (grafische Datenverarbeitung), so ist noch potential vorhanden den Code mit eigenen Assembler Routinen zu optimieren. Das habe ich gemerkt, wie ich in FreeBasic einiges gebastelt und einige Funktionen direkt in Inline ASM hinzugefügt habe -> mit relativ wenig Aufwand einiges an Performance herausgeholt.

Ich weiß nicht, ob man den optimalen Compiler bauen kann, der je nach Anwendung den effizientesten Code produziert, aber wird auch nur für spezielle Anwendungen eher nötig sein. Ich kenne mich kaum in Compilerbau aus...

Abgesehen davon gilt noch das Mooresche Gesetz und warum soll man da noch den Code optimieren denkt sich der eine oder andere Coder!?!

Wenn ich z.B. mit einer Interpreter Sprache wie AutoIt Applikationen schreiben, die relativ "schnell" arbeiten, dann benötige ich nicht zwingend einen hoch optimierten Code, der einige Millisekunden schneller arbeitet.

Ich programmiere Folgendermaßen (wenn es schnell sein muss):
1. Programm quick n Dirty zusammenstricken das die gewünschte Funktionalität zu 100% erfüllt.
2. Das gleiche Programm nochmal von Grund auf neu schreiben und dabei aus den Fehlern der Vorgängerversion lernen. Außerdem kann man das Problem auch im Kopf wesentlich effizienter lösen, wenn man schonmal ein Programm für diesen Zweck geschrieben hat. Plötzlich sieht man Wege die einem beim ersten Durchlauf nicht einfallen konnten, weil man entweder noch keinen vollständigen Überblick über das Problem hatte, oder noch nicht wusste wie man später mit zwischenzeitlich auftauchenden Daten/Rechnungen verfährt. Das alles lässt sich nun viel effizienter gestalten.
3. Optimierung von Kleinigkeiten (vorallem, wenn man nicht AutoIt nutzt und Datentypen wichtig sind) wie "ich muss viel zu viel Casten, aber wenn ich irgendwo ganz vorne einen anderen Datentyp benutze muss ich an 5 weiteren Stellen ebenfalls umschalten... usw usw" Da gibt es immer eine kleinst mögliche Anzahl Umwege (kleinst mögliche Anzahl Casts/Funktionsaufrufe/Variablen/Byref oder Byval/usw) die man versucht im Folgenden zu erreichen. (Man sucht also den Code der einen kleinen Problemausschnitt mit weniger Aufwand erledigt als vorher, ohne dabei den input oder output des Ausschnitts anzufassen)
4. F5
5. Wenn es wirklich schnell sein muss und man noch nicht zufrieden ist, zurück zu Schritt 3 gehen und etwas herumspielen und schauen was sich dadurch verändert. In vielen Fällen lassen sich da einige Prozente rausholen. (Vorallem muss man für Schritt 3 im Prinzip nichts besonderes können, man "bastelt" ja nur etwas am sowieso vorhandenen Code herum ohne ihn in irgendeiner Weise von der Funktionalität her zu verändern)

Den fertigen Code schaue ich mir aber meistens nicht an. Dafür hab ich nicht den Nerv und in vielen Fällen auch nicht die Qualifikation.

In AutoIt ist der Weg zum Tempo relativ einfach: Man nutzt stattdessen ASM
Alle Calls via Pointer aufrufbar machen. Variablen und Arrays in Structs lagern. Schleifen mit vielen Durchgängen durch ASM ersetzen. Fertig. Das macht zwar das "Umfeld" etwas langsamer (Structs sind teils langsam, dabei müssten sie eigentlich schnell sein^^), sofern der Knackpunkt aber eine einfache Stelle ist die man locker umschreiben kann gibts keine Probleme.)

Allgemein ist auch ganz praktisch: Wer Funktionen wie log, exp, pow, usw benutzt kann (falls Genauigkeit nicht wichtig ist) mit einigen wenigen Grundoperationen jedes Prozessors eine gute Approximation bekommen. Vorallem in InnerLoops haut das richtig rein, wenn man bei pow nicht 10 Schritte (angenommen die Biblipthek die man nutzt hat per default so viele), sondern nur 3 oder so benutzt.

Das war jetzt nur ganz allgemein. Der Rest wurde schon genannt, ist offensichtlich oder wird noch genannt

lg
M

Zitat von Andy

Wie programmiert/compiliert ihr? Ist (Code-)Optimierung überflüssig/überbewertet?

Für mich wäre zunächst zu klären wie Code-Optimierung hier zu sehen ist.

Wenn wir davon reden, ob/wie und in welcher Reihenfolge wir unserem Prozessor die Kommandos geben damit dieser schneller ist bin ich raus.
Ich habe mich damit noch nie richtig auseinander gesetzt. Ich weiß das es viele Themen in diesem bereich gibt, wie auch beim Speicher...

Für mich ist Code-Optimierung bislang eine oberflächliche Sache. Mit oberflächlich meine ich an dieser Stelle der Code im Editor. In dem Verbundsstudium an dem ich kurzzeitig teilgenommen habe war Code-Optimierung folgendes:
- Keine unnötigen doppelten Funktionen nutzen. Beispiel.: Keine Funktionen in Schleifen-Header verwenden wie z.B. UBound. Wenn wir uns das Ergebnis vorher in einer Variable speichern brauchen wir zwar mehr Speicher aber rufen dafür nicht in jedem Durchlauf die Funktion auf.
- Kommentare. Code ist immer nur so gut wie seine Kommentierung. Keine Kommentare, kein guter Code.
- Variablen sorgsam nutzen um des Speicher willens.
- Variablen deklarieren, initialisieren und später entsprechend "leeren".
- Lösungswege so einfach wie möglich zu gestalten.Beispiel: Wenn ich in einer Schleife eine Ausgabe mache und jede 2te Zeile anders färben/leer lassen will kann ich dies auf x-Wegen tun. Eine Variable nehmen und deren Status wechseln true/false oder ich rufe jedesmal Mod auf und werte entsprechende Ergebnisse aus oder schreibe entsprechende If-Anweisungen. Hier würde ich z.B. die einfache If-Abfrage der Mod-Funktion vorziehen.

Zu der Frage: Wie programmiert/compiliert ihr?
Ich habe bereits vor dem Studium schon sehr energisch auf diese Dinge geachtet, da dies für mich persönlich qualitative Software ausmacht. Ich programmiere aktuell ausschließlich beruflich und nicht noch zusätzlich zu Haus in meiner Freizeit. Da die Praxis oft von der Theorie abweicht und es in der Firma niemanden interessiert wie ich programmiere, solange es funktioniert und tut was es soll, halte ich mich an meinen "oberflächlichen" Optimierungen und vernachlässige die tiefere Ebene von der Andy und Xorianator in den Start-Posts reden, und selbst das ist teilweise aufgrund von Zeitmangel sehr schwierig. Kompilieren: F5.

Ich möchte nicht meine Hand ins Feuer legen ob oder ob nicht, meine "Optimierung" Einfluss auf die tiefere Ebene hat, dass weiß ich wie gesagt nicht. Ich sehe für mich persönlich (besonders in der heutigen Zeit) keinen Grund mich in diese Thematiken einzuarbeiten, was für mich jedoch am Einsatzbereich liegt. Wenn ich Hardware-nah Maschinen programmieren würde, wäre das anders. Mach ich aber nicht ... keinen Grund haben ist jedoch was anderes als es als überflüssig zu bewerten.

Sehr schöne Beiträge.....
Kann es sein, dass man hier den USER nicht beachtet? Ich lese schöner Code und denke was ist schön? Ein schönes Muster im Editor?

Schöner Code ist wenn er:

1) Funktioniert
2) Auch nach 2 Monaten noch verstanden wird
3) Im Rahmen der Aufgabenstellung schnell genug ist. Ob etwas 60 oder 100ms dauert macht keinen Sinn. Wenn es eine Schleife ist, die 500.000 durchlaufen wird, bekommt die Differenz Gewicht.
4) Wer nicht nur zum Spass programiert muss auch wirtschaftlich denken. Programme müssen/sollen bezahlbar bleiben?

Ja ein wenig Disziplin muss sein nur weil CPUs immer schneller, speicher immer mehr wird muss mann nicht wie im Kindergarten programieren - aber übertreiben muss man es auch nicht?

Worüber hier keiner spricht ist die Usability. Ich finde es macht mehr Sinn Zeit und Aufwand in die Bedienbarkeit zu stecken als das letzte Quentchen optimieren zu wollen.

Ja schon klar, das geht am rein wissenschaftlichem Ansatz vorbei....

Gruß

Peter

Man muss immer irgendwie die goldene Mitte finden.

Ich habe hier in der Diskussion eigentlich nichts zu suchen. Aber @Peter S. Taler, das ist Fachsimpelei von Leuten mit Ahnung und Spaß daran.

Denen geht es hier nicht um ein akzeptabel laufendes Programm mit verständlicher API oder intuitiver GUI.. Die wollen mehr

@autoiter -- > Das war mir schon klar.

Aber schau, genau da liegt ja der "Hund" begraben, oft fragt man sich welches Genie das geschrieben hat - weil es wirklich gut ist - nur bedienen läßt es sich schlecht - da feht dann eben auch etwas.

Gruß

Peter

Zitat von Andy

ALLES, aber auch alles in dieser ganzseitigen Anzeige in einer Fachzeitschrift schreit geradezu nach "Optimierern"

Was auch nicht ganz unverständlich ist bei Ansicht der Marktlage. Die IT Branche ist aktuell so überlaufen, dass fast jeder die Chance hat dort einen Job zu kriegen. Im Vergleich zum EInzelhandel o.ä. ist die Bezahlung dazu höher. Also hat man auch mehr qualifizierte Nieten in der Branche.

Ich hatte Leute in meiner Ausbildung in der Klasse die nur einen Hauptschulabschluss hatten, und dann beim Onkel in der Firma angestellt werden. Die haben keine einzige noch so einfache Aufgabe pünktlich gelöst, immer mit Wochen und Monaten (ein mal sogar ein halbes Jahr) Verspätung...toll ausgesehen hat es, haben das Webdesign 100% nach Google Richtlinien erstellt. Die Funktionen zur Verarbeitung der Daten haben dennoch nicht zu 30% das getan was Sie sollten.
Das waren quasi zwei Spezialisten für Anwendungen die vorne Hui und hinten Pfui sind.

@ Andy
Sorry - aber ich habe durchaus verstanden worum es geht.
Nur kommt mir der Ansatz quer vor. Etwas zu tun - weil man es kann - macht es nicht immer sinnvoller. Nach meiner Auffassung gäb es im Softwarebereich größere "Baustellen" als den Code auf Teufel komm raus zu optimieren.

Im übrigen steht dieser Beitrag doch unter Talk und nicht unter "alle sprechen über das gleiche und sind einer Meinung"? Sonst mußt Du das darüberschreiben.

Gruß

Peter

Bitte erlaubt mir als alter Gärtner ein "offtopic" Zitat:

Zitat von Bazii

Lass' die Säge sägen aber gönn' dem Baum den Ast
und wenn Du wenig Ahnung von den Dingen hast
versuch' mit langem Abstand und mit großer Weile
verzag' der scharfen Säge und der gut gemeinten Eile

Wer mein Zitat nicht kapiert hat, soll dazu 'bitte' keine Stellung nehmen. Und wer es kapiert hat, soll es bitte auch nicht tun.

Der Punkt ist nicht, dass man jedes Programm auf Teufel komm raus optimieren muss. Vielmehr geht es darum, dass z.B. an der Uni/FHS gelehrt wird, dass diese Optimierungsmöglichkeiten komplett vernachlässigbar sind. Resultat ist ein Informatiker, der noch nicht mal genau weiß, was der Compiler mit dem eigenen Code anstellt.

Klar, man braucht heutzutage kaum noch ausführliche Kenntnisse in Assembler. Ein Webprogrammierer z.B. überhaupt nicht. Wenn ich aber an der Uni nur Java lehre und sage, dass alles auf einer tieferen Abstraktionsschicht "veraltet und unwichtig" ist... Dann hat der angehende Softwareentwickler ja noch nicht mal die Möglichkeit, sein Programm auf dieser Ebene zu optimieren, völlig egal, ob es nötig ist oder nicht! Pauschal auf solche Grundlagen zu verzichten halte ich auch für falsch.

Man muss dabei sagen, dass das auf mich nicht zutrifft. Ich studiere keine "normale" Informatik, sondern Ingenieur-Informatik. In den ersten beiden Semestern gibt es Java/OOP, danach kommt Mikroprozessortechnik etc. mit C und Assembler. Der Großteil der Informatik-Studenten kommt allerdings nicht über Java hinaus.