Wie programmiere ich performant? Literaturtipps?
-
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.
-
hustbaer schrieb:
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.
Es ist aber wohl eines der unwichtigsten Dinge wenn es um Performance geht. Bevor man krampfhaft versuch kleinen Code zu schreiben gibt es 1000 andere Dinge die wichtiger sind. Das ist einfach das Problem bei solchen Threads, dass hier immer wieder solche "tollen Tricks" aufgezählt werden und einige Leute dann versuchen so ihren Code schnell zu bekommen, anstatt die passenden Algorithmen und Datenstrukturen zu verwenden.
-
hustbaer schrieb:
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?).wenn man den code fuer den compiler freundlich schreibt, dann kann er das mitlerweile zu nem gewissen grad vektorisieren. besonders bei speicherverschiebung laeuft das recht gut, ob das auf mul zutrifft kann ich jedoch nicht sagen. jedoch bezog sich meine antwort rein darauf, dass bit-shift in SSE immer noch nicht geht
-
Byty schrieb:
rapso schrieb:
Kilo Byte = 1000, 1 Kilobyte = 1024, da Eigenbegriff
falsch, 1 kilobyte = 1000 bytes. 1024 bytes = 1 kibibyte.
als das kilobyte erfunden wurde vor jahrzehnten, gab es sicher kein kiwibyte.
-
och nö schrieb:
hustbaer schrieb:
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.
Es ist aber wohl eines der unwichtigsten Dinge wenn es um Performance geht. Bevor man krampfhaft versuch kleinen Code zu schreiben gibt es 1000 andere Dinge die wichtiger sind. Das ist einfach das Problem bei solchen Threads, dass hier immer wieder solche "tollen Tricks" aufgezählt werden und einige Leute dann versuchen so ihren Code schnell zu bekommen, anstatt die passenden Algorithmen und Datenstrukturen zu verwenden.
da stimm ich zu. die ganzen tips sind oft kontraproduktiv, da sie stumpf befolgt werden. wenn man schnellen code schreiben moechte, muss man nachdenken und keine stumpfen abfolgen abarbeiten, denn was in einem fall gut ist, kann im anderen kontraproduktiv sein.
Das beste ist, einen Profiler laufen zu lassen und rauszufinden wie es geht.
-
rapso schrieb:
Byty schrieb:
rapso schrieb:
Kilo Byte = 1000, 1 Kilobyte = 1024, da Eigenbegriff
falsch, 1 kilobyte = 1000 bytes. 1024 bytes = 1 kibibyte.
als das kilobyte erfunden wurde vor jahrzehnten, gab es sicher kein kiwibyte.
Da war ursprünglich auch eher nicht die Rede von Kilobyte sondern von KByte oder KB oä. Kilo ist nunmal Tausend, daran ändern auch ein paar Informatiker nichts.
Aber lassen wir die Diskussion hier raus, sie passt (a) überhaupt nicht zum Thema und wurde (b) schon viel zu oft geführt.
-
nman schrieb:
Kilo ist nunmal Tausend, daran ändern auch ein paar Informatiker nichts.
Dafür aber der allgemeine Sprachgebrauch.
Daran ändern auch ein paar Tausend-Prozentige mit ihrere Kibi-Korinthe nichts.
-
Jester schrieb:
nman schrieb:
Kilo ist nunmal Tausend, daran ändern auch ein paar Informatiker nichts.
Dafür aber der allgemeine Sprachgebrauch.
Daran ändern auch ein paar Tausend-Prozentige mit ihrere Kibi-Korinthe nichts.Allgemeiner Sprachgebrauch ist das ja nur in Informatikerkreisen. Frag doch mal ein paar weniger informatik-affine Biologen, Chemiker, Physiker oä. wieviel Megabyte ein Gigabyte hat.
edit: Argh, nein. Darf... nicht... darüber... reden. Lassen wir es einfach, ja? Wir könnten genausogut über ungarische Notation diskutieren, wäre ähnlich zielführend und genauso On-Topic.
-
Ich glaube zwei allgemeine Tipps kann man in dem Bereich geben
1. Code so leserlich wie möglich zu schreiben: Was man selbst gut versteht, versteht der Optimizer idr auch gut. (=> nicht einfach blind obskure oder schlechte Konstrukte benutzen, weil man glaubt sie machen den Code schneller oder das bei einem C Compiler für einen µC in den 80ern funktioniert hat)
2. "Optimierungen" immer mit einem Profiler/Benchmark kontrollieren und nicht blind optimieren.
-
-
nman schrieb:
... Kilo ist nunmal Tausend...
genau das steht ja auch in meiner signatur.
wir streiten uns ja auch nicht dass pferdeapfel nicht so heissen darf, weil ein kleinkind (also jemand der es nicht besser weiss), das mit einem pferde apfel verwechselt.
-
rüdiger schrieb:
1. Code so leserlich wie möglich zu schreiben: Was man selbst gut versteht, versteht der Optimizer idr auch gut. (=> nicht einfach blind obskure oder schlechte Konstrukte benutzen, weil man glaubt sie machen den Code schneller oder das bei einem C Compiler für einen µC in den 80ern funktioniert hat)
darunter kann ich mir viel vorstellen, aber ich weiss nicht ob du's meintest, kannst du ein beispiel geben?
-
nman schrieb:
Frag doch mal ein paar weniger informatik-affine Biologen, Chemiker, Physiker oä. wieviel Megabyte ein Gigabyte hat.
ich hab gerade einen physiker gefragt was ein kilobyte ist, er meinte 1024byte (macht gerade dipl-arbeit), dann fragte ich was ein kibibyte ist, er meinte er hat das nie vorher gehoert, es koennten aber 1024 bit sein, weil es vielleicht kilobit ausgeschrieben ist.
-
rapso schrieb:
rüdiger schrieb:
1. Code so leserlich wie möglich zu schreiben: Was man selbst gut versteht, versteht der Optimizer idr auch gut. (=> nicht einfach blind obskure oder schlechte Konstrukte benutzen, weil man glaubt sie machen den Code schneller oder das bei einem C Compiler für einen µC in den 80ern funktioniert hat)
darunter kann ich mir viel vorstellen, aber ich weiss nicht ob du's meintest, kannst du ein beispiel geben?
Ist ja auch eine allgemeine Regel. Das besagt einfach nur, dass man nicht blind wirre und unleserliche Konstrukte benutzen sollte.
-
rüdiger schrieb:
rapso schrieb:
rüdiger schrieb:
1. Code so leserlich wie möglich zu schreiben: Was man selbst gut versteht, versteht der Optimizer idr auch gut. (=> nicht einfach blind obskure oder schlechte Konstrukte benutzen, weil man glaubt sie machen den Code schneller oder das bei einem C Compiler für einen µC in den 80ern funktioniert hat)
darunter kann ich mir viel vorstellen, aber ich weiss nicht ob du's meintest, kannst du ein beispiel geben?
Ist ja auch eine allgemeine Regel. Das besagt einfach nur, dass man nicht blind wirre und unleserliche Konstrukte benutzen sollte.
ich frage mich nur, was ein kompiler in simpler form hingeschrieben besser versteht als wenn man es 'wirr' schreibt. ('wirr' ist so weitlaeufig interpretierbar:) ). ich dachte du haettest etwas konkretes im sinn. Schade.
-
@rapso
konkret könnte man zB Verwendung von #define oder einfach Shiften anstelle zu dividieren/multiplizieren etc. Halt Dinge, die dem Compiler verbergen was man eigentlich vor hat.
-
Rapso: Du merkst schon, dass der Thread hier von uns verunstaltet wird, weil Du auf einen unregistrierten Troll eingestiegen bist? Wenn Du das gerne weiterdiskutieren möchtest, dann mach doch einen neuen Thread auf, oder grab einen der vielen alten Threads dazu wieder aus, ich bin eigentlich nicht wahnsinnig an diesem Thema interessiert, werde mich ab jetzt zurückhalten, sorry.
rapso schrieb:
ich hab gerade einen physiker gefragt was ein kilobyte ist, er meinte 1024byte (macht gerade dipl-arbeit), dann fragte ich was ein kibibyte ist, er meinte er hat das nie vorher gehoert, es koennten aber 1024 bit sein, weil es vielleicht kilobit ausgeschrieben ist.
Dann frag ein paar mehr und mach eine repräsentative Umfrage daraus. Kibibyte muss niemand kennen, aber Kilobyte sind 1000 Byte, besonders in Wissenschaftszweigen, wo man auch ein bisschen was auf SI-Konformität hält. Die Physiker in meinen Bekanntenkreisen lachen nur über die Diskussion und ich verstehe das gut.
-
rüdiger schrieb:
@rapso
konkret könnte man zB Verwendung von #define oder einfach Shiften anstelle zu dividieren/multiplizieren etc. Halt Dinge, die dem Compiler verbergen was man eigentlich vor hat.Und da kann der Optimierer dann besser optimieren? Und irgendwie hatte ich immer den Eindruck, dass Makros den Code leserlicher macht als wenn man den Makrocode direkt einbindet.
