Wie programmiere ich performant? Literaturtipps?
-
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.
-
nman schrieb:
...weil Du auf einen unregistrierten Troll eingestiegen bist
Unreg-Bashing
Und das von einem Moderator
-
Tim schrieb:
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.
Wer sagt, dass du Makrocode direkt einbinden sollst? Es gibt ja auch andere Möglichkeiten (static const/inline). Aber das ist sicher kein Fall wo der Optimierer von profitiert. Das bringt eher was beim debuggen und verständliche Fehlermeldungen...
-
rüdiger schrieb:
Tim schrieb:
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.
Wer sagt, dass du Makrocode direkt einbinden sollst? Es gibt ja auch andere Möglichkeiten (static const/inline). Aber das ist sicher kein Fall wo der Optimierer von profitiert. Das bringt eher was beim debuggen und verständliche Fehlermeldungen...
Aber ein inline ist, wie wir das leider schon oft hatten, nur ein hint. Aber lassen wir das. Du weisst was ich meine und umgekehrt
-
nman schrieb:
Rapso: Du merkst schon, dass der Thread hier von uns verunstaltet wird, weil Du auf einen unregistrierten Troll eingestiegen bist?
nur weil er unreg ist und ne andere meinung hat, muss er kein Troll sein;)
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.
vielleicht kann ja auch ein mod die 5beitraege raussplitten.
rapso schrieb:
Dann frag ein paar mehr und mach eine repräsentative Umfrage daraus
erst soll ich nur physiker fragen und jetzt representativ? und wenn dabei rauskommt dass sie wissen was kilobyte bedeutet soll ich... klar
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.
mein kumpel lacht auch drueber, er meint dass sie unmengen von einheiten haben, oft fuer ein und die selbe sache sogar und die meisten nicht physiker das meiste auch falsch oder garnicht interpretieren koennen. aber nun da er weiss was Kibi ist, ist er weiterhin so dumm wie jemand der watt als mass fuer lichtstaerke von gluehbirnen nutzt.
-
rapso schrieb:
nman schrieb:
Rapso: Du merkst schon, dass der Thread hier von uns verunstaltet wird, weil Du auf einen unregistrierten Troll eingestiegen bist?
nur weil er unreg ist und ne andere meinung hat, muss er kein Troll sein;)
Er hat ja die gleiche Meinung wie ich. Aber das war trotzdem ein Troll.
rapso schrieb:
soll ich nur physiker fragen und jetzt representativ? und wenn dabei rauskommt dass sie wissen was kilobyte bedeutet soll ich... klar
Hehe, nein, Du solltest "ein paar weniger informatik-affine Biologen, Chemiker, Physiker oä" fragen, nicht einen einzelnen Physiker.
-
rapso schrieb:
...so dumm wie jemand der watt als mass fuer lichtstaerke von gluehbirnen nutzt.
Wobei man wissen sollte, daß es zwischen Leistungsaufnahme und Lichtausbeute von Glühbirnen einen direkten Zusammenhang gibt.
-
UnregistrierterNichtTroll schrieb:
rapso schrieb:
...so dumm wie jemand der watt als mass fuer lichtstaerke von gluehbirnen nutzt.
Wobei man wissen sollte, daß es zwischen Leistungsaufnahme und Lichtausbeute von Glühbirnen einen direkten Zusammenhang gibt.
Blitzmerker.
-
Kinder, Kinder, nun hört schon auf zu streiten...
Eigentlich fand ich ganz schön, wie sich der Thread entwickelt hat, was das eigentliche Thema anging, dazu allen vielen Dank!
Ich wollte nur nochmal sagen, warum ich die Algorithmen-Bücher nicht allgemein genug finde, und dass ich was anderes brauch. Die späteren Literaturtipps konnte ich aber noch nicht ausprobieren...
Also:
In den meisten Büchrn, die ich so gesehen habe, stehen tolle möglichkeiten für Standard-Algorithmen drin. Da ich die nicht brauche, kann ich damit auch wenig anfangen. Ic muss weder sortieren noch (hier bitte weiteres Standardthema einfügen)
Ich habe es mit Audio-Signalverarbeitung zu tun und daher mit ziemlich großen Datenmengen, die durch ziemlich stumpfe berechnungen geschickt werden... Mir lag eher was daran, allgemeine Regeln, die auch im Thread aufgetaucht sind, zu lernen...
Vielen Dank schonmal
Sören
-
Hättest ja auch mal am Anfang schreiben können was du vor hast. Zuerst solltest du mal mit nem Profiler schauen, was wirklich lange braucht. Dann schaust du ob es für diesen Teil (oder den darum) nen besseren Algorithmus gibt. Wenn nicht, kannst du immer noch versuchen den Code zu optimieren, wobei du damit wahrscheinlich nur ein paar Prozent gewinnen kannst, außer du hast wirklich schlecht programmiert.
-
@soerenP: Auch bei Audio Signalverarbeitung gibts verschiedene Algorithmen die man für die selbe Aufgabe verwenden kann. Einen FIR Filter kann man z.B. stur mit Kreuzkorrelation berechnen, oder mit Hilfe einer FFT/IFFT, was viel schneller geht.
-
hustbaer schrieb:
Einen FIR Filter kann man z.B. stur mit Kreuzkorrelation berechnen, oder mit Hilfe einer FFT/IFFT, was viel schneller geht.
normalerweise wird, aus geschwindigkeitsgründen, bei FIR filtern mit konstanten gearbeitet, so dass man zur laufzeit keine aufwendigen berechnungen wie FFT mehr machen muss.
-
@DSP-freak:
Ich weiss nicht genau was du meinst. Ich spreche von langen FIR Filtern wo nahezu alle Koeffizienten ungleich 0 sind - was willst du da mit "Konstanten" optimieren?
-
mit konstanten meinte ich die koeffizienten. sampling-wert kommt in einen ringuffer, dann werden alle elemente des buffers mit dem dazugehörigen koeffizienten multipliziert, der output berechnet (z.b. mittelwert von allem). danach wird der buffer eins weitergeschoben, wobei das älteste element rausfliegt. usw.usw..
-
Mein lieber DSP-Freak,
dann hast du wohl noch nie FIR-Filter mit längeren koeffizientensätzen probiert... (ohne DSP) Da geht nämlich ohne FFT-Faltung gar nichts. Und die muss man wohl zur laufzeit durchführen, die koeffizienten kann man zwar vorher transformieren, aber der Audio-Input ist (zumindest bei mir ) immer noch zur Laufzeit erstellt...
Falls dir das Prinzip ungeläufig ist:
Input und Koeffizienten werden über FFT in den Frequenzbereich transformiert, dort wird eine komplexe Multiplikation durchgeführt, was viel schneller geht als eine Faltung (n berechnungen anstatt n*n) da die FFT ab einer bestimmten Puffergröße viel schneller ist als eine normale Transormation (die so lange dauern würde wie die brute force faltung) kann man so immens Zeit sparen.
@alle anderen:
Ja, klar kann ich über die richtigen Algorithmen Zeit sparen, wie man sieht, aber wenn man mal keinen Standard braucht, wer sagt mir, wie ich vorgehen soll?
Ich bin mir sicher, dass in meinem Programm so unglaubliche Schnitzer drin sind, für deren verbesserung mir bestimmt kein Algorithmen-Buch hilft.
Algorithmen sind ja auch eher Mathematischer Natur. Ich meine, ein Algorithmus kann bestimmt ganz toll sein (z.B. FFT), ein ahnungsloser Mathematiker könnte ihn aber unter Umständen sehr schlecht in Code übersetzen, z.B. weil er nicht weiss, dass Speicherzugriff auch Zeit kostet, oder wie auch immer. Versteht ihr, was ich meine?
Viele Grüße
Sören
-
Nochmal, um meine Misere etwas zu erläutern:
Ich bin dabei, einen Synthesizer für die VST-Schnittstelle zu basteln. Läuft auch, alles kein Thema. Er basiert auf dem Karplus-Strong algorithmus, im Prinzip nur eine Verzögerung, die der Periodendauer entspricht, eine Anregungsfunktion und ein Filter, der die Höhen rausnimmt im Verlauf der Schwingung. (den ich aber auch deaktiviert habe, um zu schauen, wieviel Leistung er frisst). Alles mit Sicherheit kein Hexenwerk. Wenn ich davon aber 5 Stimmen Spiele (ohne Filter) ist mein Turion Dual Core schon zu 50% ausgelastet. Da ist bestimmt was ziemlich im Argen und meine Algorithmen sind meiner Meinung nach so simpel, dass sie nicht wirklich zu vereinfachen sind. Ich bin fast der Meinung, dass man die eigentlich nicht so schlecht hinbekommen kann, dass ich ein solches Ergebnis bekomme...
Naja...
Grüße
Sören
-
hast du jetzt schon mal nen profiler verwendet?
