Wie programmiere ich performant? Literaturtipps?
-
Hört sich auf den ersten Blick nicht so allgemein an (Algorithmen), wie ichs gerne hätte, aber ich schau auf jeden Fall mal nach, danke!
-
fooBarFighter schrieb:
Meinst du jetzt wie man möglichst wenig Tastendrücke braucht? Oder willst du performante Programme schreiben?
Nein, die Programme sollten performant werden. So faul bin ich dann doch nicht
-
Also, ich hatte mir in etwa so etwas vogestellt:
Was sollte man in seinem Programm vermeiden? Was frisst unnötig Prozessorleistung?
Wo lohnt es sich z.B. an Überichlichkeit zu sparen, wenn es dafür schneller wird...
Wie regele ich am besten die Kommunikation zwischen Objekten?
-
Es gibt keine einfache Antwort auf diese Frage. Warum das so ist kann man in diesem Artikel gut nachlesen:
-
Ich finde, Du solltest TAOCP lesen.
-
Ich kenn nur TAFKAP
Nein, habs gegooglet, ich schaus mir mal an.
Vielen Dank an alle!
Sören
-
Hi,
versuchs mal mit
Scott Meyers Effektiv C++ programmieren"
Scott Meyers "Mehr Effektiv C++ programmieren"
oder ich sag mal so: Kreative Faulheit. Nichts machen was nicht muß und immer nur das machen was muß und nichts doppelt.
Keine Objekte mit Standardargumenten erstellen und dann ändern, sondern gleich mit aktuellen Argumenten erstellen.
Nur das berechnen, was auch wirklich weiter verwendet wird.
Mit Exceptions sparsam umgehen, nicht als Steuerstrukturen verwenden...
Niedrige Operationen verwenden, also besser Shift als Multiplikation wenn das möglich ist, Addition vor Multiplikation, zur Compilezeit berechenbare Werte auch dort berechnen, tief geschachtelte Felder vermeiden...
Und letztlich gilt immer noch, daß kleinere Programme nicht so viel Code durchschleusen müssen und daher schon von Hause aus eine Chance haben effizienter zu sein. (natürlich bei sonst gleicher Programmqualität.)Gruß Mümmel
-
soerenP schrieb:
Hört sich auf den ersten Blick nicht so allgemein an (Algorithmen), wie ichs gerne hätte, aber ich schau auf jeden Fall mal nach, danke!
Du suchst was allgemeineres als das?
-
muemmel schrieb:
Niedrige Operationen verwenden, also besser Shift als Multiplikation wenn das möglich ist,
Ein klassisches Beispiel für premature Optimizing... Auf modernen Prozessoren können Multiplikationen sogar schneller sein als bit-shifting.
-
skals schrieb:
Auf modernen Prozessoren können Multiplikationen sogar schneller sein als bit-shifting.
Achja? Nenne bitte ein Beispiel!
-
Egal was von beiden schneller ist, von einem zeitgemäßen Compiler kann man erwarten, daß er vernünftig optimiert. Und die Entscheidung ob Shift oder Multiplikation schneller ist, dürfte eine der einfachsten sein.
-
hustbaer schrieb:
skals schrieb:
Auf modernen Prozessoren können Multiplikationen sogar schneller sein als bit-shifting.
Achja? Nenne bitte ein Beispiel!
jede cpu mit SSE.
-
Vielleicht suchst du sowas:
Efficient C++ | ISBN: 0201379503
-
rapso schrieb:
Kilo Byte = 1000, 1 Kilobyte = 1024, da Eigenbegriff
falsch, 1 kilobyte = 1000 bytes. 1024 bytes = 1 kibibyte.
-
Du solltest besonders auf minmalen Speicherverbrauch achten! Speicherzugriffe sind im Vergleich zu der Rechengeschwindigkeit moderne CPUs teuer!
-
muemmel schrieb:
Und letztlich gilt immer noch, daß kleinere Programme nicht so viel Code durchschleusen müssen und daher schon von Hause aus eine Chance haben effizienter zu sein. (natürlich bei sonst gleicher Programmqualität.)
Nicht wirklich.
-
rapso schrieb:
hustbaer schrieb:
skals schrieb:
Auf modernen Prozessoren können Multiplikationen sogar schneller sein als bit-shifting.
Achja? Nenne bitte ein Beispiel!
jede cpu mit SSE.
Hihi, ok, wenn was parallel geht dann stimmt das
Die muss man halt im Moment selbst mit intrinsics/inline asm schreiben da es noch keinen wirklich guten SSE Vectorizer gibt (oder bin ich nur nichtmehr am Laufenden?).-----
z.T. Programmgrösse: es kommt eigentlich nur drauf an wie gross der oft durchlaufene Code im Vergleich zum Cache ist. Wenn ein Programm komplett in den Cache passt, ein anderes (welches das gleiche tut) dagegen nicht, dann macht das schon meist einen Unterschied.
Wenn beide komplett in den L1 Cache passen ist es natürlich egal.
-
Das kommt drauf an. Der Algorithmus ist entscheidender.
Besser nen Quicksort der nicht in den L1 Cache passt als ein Bubbe sort der reinpasst.
-
bevor man performant programmiert, sollte man lernen, effizient zu programmieren. das erste ziel sollte immer ein solider entwurf sein. fragen die man dabei bewegen sollte sind:
- was genau ist das problem
- lässt sich das problem durch ein standard pattern abbilden (ist in 95% der fälle wahr)
- welche teilaufgaben gibt es und welche algorithmen werden benötigtwenn man das alles weiss, hat man schon die halbe miete. optimierung von performanz ist dann eine detailaufgabe.
zur frage effizienz ist das buch "der pragmatische programmierer" relativ empfehlenswert.
-
MisterX schrieb:
Das kommt drauf an. Der Algorithmus ist entscheidender.
Besser nen Quicksort der nicht in den L1 Cache passt als ein Bubbe sort der reinpasst.
Richtig.
Ich bin davon ausgegangen dass beide Programme die gleichen Algorithmen verwenden, obwohl das aus meinem Posting nicht klar hervorgeht wie ich jetzt sehe.Und man könnte das wahrscheinlich noch unendlich lange fortsetzen mit anderen Dingen (Quicksort ist z.B. nicht optimal für jeden Input was Grösse angeht oder ob die Elemente schon grossteils "vorsortiert" sind uswusf).
Ich wollte eigentlich nur feststellen dass Codegrösse sehr wohl einen Einfluss haben kann. Wie gross der ist und ob nicht andere Faktoren überwiegen ist wieder eine andere Sache, am Besten man probiert es einfach aus.
Genauso (was aber schon erwähnt wurde) kann es einen Unterschied machen wieviel Byte/KB/MB an Daten man angreifen muss, und in welcher Reihenfolge man die Zugriffe macht.
