Notwendige Rechenleistung feststellen
-
Hi,
Momentan schreibe ich an einem Programm, welches kontinuierlich Messwerte entgegen nimmt, diese verrechnet und ein Ergebnis ausgibt.
Es soll später auf einem relativ langsamen Rechner, dessen Merkmale ich nicht kenne, laufen.Gibt es eine Norm, wie man die absolut benötigte Rechenzeit für ein Programm angibt, bzw. diese experimentell bestimmen kann? Diese Angabe sollte möglichst geeignet sein, einen geeigneten Rechner auszuwählen.
Danke!
-
-
roi_de_moi schrieb:
Ist in diesem Fall leider nicht geeignet.
-
Es scheint nicht möglich, bzw. zu komplex, das auf ein ganzes Programm anzuwenden, oder?
-
Mercator schrieb:
Es scheint nicht möglich, bzw. zu komplex, das auf ein ganzes Programm anzuwenden, oder?
Nein. Das waere wohl nicht sinnvoll.
Ich denke da gibt es nichts anders als Erfahrung und Testen. Das kann man wohl nur ganz grob abschaetzen.
-
Naja, es gibt schon praktische Wege. Das Problem ist, dass die heutigen Desktop-CPUs nicht sehr vorhersehbar sind, da sie intern alle möglichen Tricks benutzen. Aber konservativ nach oben kann man eh abschätzen und wenn du einen einfacheren Prozessor (zB DSP oder µC) nimmst, dann kann man den Zeitaufwand ziemlich genau abschätzen. Du weißt ja vermutlich wie viele Operationen du pro Messwert ausführen musst. Dann kannst du nachschauen wie viele Taktzyklen der Prozessor pro Operation braucht und musst es nur aufsummieren und dann die Zeit ausrechnen. Wenn du so etwas wie einen Precedence-Graph machst (macht man wohl üblicherweise bei DSP-Programmierung), dann kannst du sogar mehrere Recheneinheiten/Parallelisierung mit einbeziehen.
-
Ditto
In etwa bestimmen kann man schon, aber die Ungenauigkeit bzw. Rechenmöglichkeit liegt nicht nur beim Betriebsystem, sondern auch bei der Hardware
(Cachegröße, Trefferraten, Ram, Festplattenperformance, Datenübertragungszeit, Timings auf dem Motherboard, Paralleliserung, Festkommaperformance, spezielle Hardwarebeschleunigung von Programmtypen usw.)
und natürlich bei den Algorithmen und Anzahl der Sprünge und Verzweigungen/Interaktionen im Programm.
Zu Algorithmen siehe z.B.:
http://www-i1.informatik.rwth-aachen.de/~algorithmus/algo25.php
Und auch Compiler spielen eine Rolle, oder ob man mit einem Profiler arbeitet.Also: testen
wie etwa
http://www.bernd-leitenberger.de/fractale.shtml
http://www.bernd-leitenberger.de/benchmark.shtml
und natürlich Tabellen erstellen, rechnen und interpolieren.Eine gutes empirisches Werkzeug liefern bei manchen Leuten sicher auch die ausgedienten Althandys, wenn man das Programm in Java schreibt und dann bei verschiedenen Handys ermittelt, wie lange sie brauchen, aber das kann man nicht unbedingt auf nicht-javabeschleunigte Prozessoren übertragen.
Eine recht praktische Norm bei filmischer Grafikausgabe sind Bilder/Sekunde.
Bei reiner Rechnerei ist noch ein typischer Normbegriff, ob man mit einfacher oder doppelter Genauigkeit rechnet.
http://de.wikipedia.org/wiki/Doppelte_Genauigkeit
http://de.wikipedia.org/wiki/Einfache_Genauigkeit
-
roi_de_moi schrieb:
http://de.wikipedia.org/wiki/KomplexitätstheorieIst in diesem Fall leider nicht geeignet.
Warum nicht ?
Wer weis wie komplex die Berechnung ist ? Und wenn ich eine Komplexitätsanalyse mache, finde ich unter anderem auch genau die Stellen an denen sich eine weitere (Mikro-) Optimierung lohnt.
Deswegen mein Vorschlag:
1.) Durchführen einer Komplexitätsanalyse. Wo verbraucht mein Program die meiste Zeit ?
2.) Nachschauen ob es Algorithmen mit einer besseren Komplexitätsklasse gibt s.d. bespielsweise aus O(n^2) O(log(n)) wird.
3.) Nach Bedarf eine Optimierung durchführen in dem man versucht die inneren Schleifen zu optimieren s.d. bespielsweise aus O(log(n)) 0.5*O(log(n)) wird. Dazu kann man auch gut die Hardware nutzen (OpenMP).
4.) Compiler auf höchste Optimierungstufe stellen und mal im Disassembly nachschauen wie der Compiler optimiert. Nach Bedarf eine Mikrooptimierung durchführen.
-
deine vorschläge sind gut geeignet, um performance bottlenecks zu finden und zu beheben. aber allgemeine systemanforderungen kann man daraus nicht ableiten. selbst wenn man alle algorithmen auf O(log(n)) optimiert, benötigt die ausführung ja trotzdem noch zeit.
-
Bitte ein Bit schrieb:
3.) Nach Bedarf eine Optimierung durchführen in dem man versucht die inneren Schleifen zu optimieren s.d. bespielsweise aus O(log(n)) 0.5*O(log(n)) wird.
Die Aussage ergibt keinen Sinn.
-
wenn dein program laeuft, kannst du die reele laufzeit messen und vom tasksystem deines betriebssystems die verbrauchte rechenzeit ermitteln. dann weisst du zu wieviel % du deine cpu nutzt und kannst in etwa abschaetzen, wie stark die minimal cpu sein muesste.
das setzt natuerlich voraus, dass deine software entweder relativ gleichmaessig laeuft oder dass sie wenigstens nicht zeitkritisch ist (ansonsten muesstest du dich nach der peak leistung orientieren, was schwerer zu messen ist).
auf der guten seite hat das verfahren, dass es relativ genau ist bei cpu limitierten programmen, selbst wenn du auf einer monster kiste nur 5% der rechenzeit ueber einen tag hinweg verbrauchst.
du solltest allerdings vorsichtig sein mit threads, 12.5% der rechenzeit eines intel i7 kann bedeuten dass du zwar nur 12.5% verbrauchst, aber dennoch kannst du keinen singlecore mit <2GHz takt auf die sache ansetzen.
-
Mercator schrieb:
Gibt es eine Norm, wie man die absolut benötigte Rechenzeit für ein Programm angibt, bzw. diese experimentell bestimmen kann? Diese Angabe sollte möglichst geeignet sein, einen geeigneten Rechner auszuwählen.
Rein theoretisch müsste das gehen.
Bei Assemblerbefehlen gibt der Hersteller auch an, wieviel Taktzyklen ein Befehl braucht. Wenn man dann die Anzahl der Taktzyklen des Programm mit dem Kehrwert des CPU-Takts verrechnet, kann man wirklich im Nanosekundenbereich berechnen, wie lange die Abarbeitung des Programms dauert.Liebe Grüße
Steffo
-
Ich werde es dann wohl experimentell machen. Scheint mir noch das einfachste zu sein.
-
Steffo schrieb:
Mercator schrieb:
Gibt es eine Norm, wie man die absolut benötigte Rechenzeit für ein Programm angibt, bzw. diese experimentell bestimmen kann? Diese Angabe sollte möglichst geeignet sein, einen geeigneten Rechner auszuwählen.
Rein theoretisch müsste das gehen.
Bei Assemblerbefehlen gibt der Hersteller auch an, wieviel Taktzyklen ein Befehl braucht. Wenn man dann die Anzahl der Taktzyklen des Programm mit dem Kehrwert des CPU-Takts verrechnet, kann man wirklich im Nanosekundenbereich berechnen, wie lange die Abarbeitung des Programms dauert.Nein. Zumindest nicht mit so einer einfachen Rechnung oder nur bei sehr einfachen Programmen. Da fließen zu viele andere Dinge mit ein, die großen Einfluss haben. Cache, Pipelines, Sprungvorhersage allein schon im Prozessor. Darüber hinaus auch noch die anderen Komponenten, das Programm will ja sicherlich auch mal auf den Arbeitsspeicher und die Festplatte zugreifen.
-
SeppJ schrieb:
Steffo schrieb:
Mercator schrieb:
Gibt es eine Norm, wie man die absolut benötigte Rechenzeit für ein Programm angibt, bzw. diese experimentell bestimmen kann? Diese Angabe sollte möglichst geeignet sein, einen geeigneten Rechner auszuwählen.
Rein theoretisch müsste das gehen.
Bei Assemblerbefehlen gibt der Hersteller auch an, wieviel Taktzyklen ein Befehl braucht. Wenn man dann die Anzahl der Taktzyklen des Programm mit dem Kehrwert des CPU-Takts verrechnet, kann man wirklich im Nanosekundenbereich berechnen, wie lange die Abarbeitung des Programms dauert.Nein. Zumindest nicht mit so einer einfachen Rechnung oder nur bei sehr einfachen Programmen. Da fließen zu viele andere Dinge mit ein, die großen Einfluss haben. Cache, Pipelines, Sprungvorhersage allein schon im Prozessor. Darüber hinaus auch noch die anderen Komponenten, das Programm will ja sicherlich auch mal auf den Arbeitsspeicher und die Festplatte zugreifen.
Bei komplizierten CPUs ist es in der Tat schwierig. Man kann zwar immer noch gut nach oben abschätzen. Das Ergebnis kann dann natürlich ziemlich daneben liegen. Aber für komplizierte CPUs braucht man doch selten so präzise Abschätzungen. Geht es um die Massenproduktion und man will jeden cent einsparen, dann geht es doch vermutlich eh um DSPs/µCs. Und die sind ja deutlich simpler als eine Desktop-CPU und erlauben daher deutlich realistischeres abschätzen. Wenn es um ein einzelnes System geht, dann dürften die Anschaffungskosten doch kaum auffallen im Vergleich zu den Kosten des Entwicklers. Macht man sich da wirklich eine Woche Gedanken ob man lieber eine CPU für 200€ oder 500€ kauft?
