Hallo,
ich will ein komplexes Programm mit Gprof Analysieren.
Aber die 0,01 Sekunden Taklung sind viel zu lang.
Erst wenn ich lange Warte Schleifen einbaue bekomme ich überhaupt mal
einen Wert raus.
Das Programm läuft normalerweise auf einem 68K und ist reiner simpler
C-Code.
Die normale Verarbeitungszeit auf dem 68K liegt bei ca. 1,7ms.
Den muss ich jetzt aber unter 1,499ms bekommen.
Den Code habe ich zum testen einfache mal als DOS Programm kompiliert
und Gprof drauf angesetzt, Resultat alle Zeiten sind bei 0, was soviel
bedeutet wie zu schnell.
Hat jemand eine Idee wie ich das Timming verändern kann oder gibt es
eine andere Möglichkeit (Prozessor/Simulator/...) um ein Programm
vernünftig zu Analysieren?
Viele Grüsse, Peter
Dein Codeteil soll vermutlich zyklisch auf dem 68K aufgerufen werden,
braucht jetzt aber noch 1.7ms pro Schleife und damit zuviel, korrekt?
Ich denke nicht, dass Dir dabei eine gprof Analyse basierend auf einem
DOS Programm hilft. Damit optimierst Du das Timing auf einer Intel
Plattform, aber nicht unbedingt auf einem 68K.
(BTW: hast Du geprüft, ob es einen funktionierenden gprof für 68K plus
einen 68K Simulator gibt? Wenn dein Code unter DOS läuft (sprich ohne
hardwarenahe Funktionen) müsste das Ganze auch unter einem 68K Simulator
laufen…)
Wenn ich mich recht erinnere, ermittelt gprof seine Daten mittels
zyklischem Sampling des Programm Counters. Es ist ein statistisches
Verfahren und hier IMHO nicht sinnvoll einsetzbar.
Ich würde eher den Code per Hand instrumentieren und auf der 68K
Zielplatform die Zeiten messen.
Sprich: An strategischen Stellen speicherst Du den Stand eines
freilaufenden Timers ab. Die Differenz zwischen zwei Werten entspricht
der Laufzeit. Natürlich beeinflusst der zusätzliche Code deine Messung,
aber das ist meist zu verschmerzen.
Konrad S. schrieb:> Was spricht dagegen, den relevanten Code in einer Schleife so oft> aufzurufen bis die gemessenen Zeiten aussagekräftig werden?
Ich bin davon ausgegangen, dass Peter das bereits gemacht hat.
Wenn er gprof nutzt, müsste er das wissen / ist es naheliegend.
(Mmm, hat er...? Warten wir's ab ob er sich nochmal meldet...)
Sagen wir mal so, ich habe es einige tausend mal durchlaufen lassen.
Hätte dann wohl einige hunderttausend nehmen sollen oder?
Habe gerade meinen Test 200.000 mal durchlaufen lassen und oh Wunder ich
habe tatsächlich 0,05sec gesamt Laufzeit.
Ist ein Anfang, muss jetzt nur noch optimiert werden.
Das es große unterscheide gibt wo und mit was man den Code Kompiliert
ist mir schon klar.
Der original Compiler ist leider keiner mit Gpgrof. Einen GCC habe ich
zwar für den 68K aber getestet habe ich den noch nie.
Ein 68K Simulator habe ich bis jetzt noch nicht gesucht. Aber da wird es
genug geben.
Ich wollte halt überhaupt mal einen Überblick bekommen wo den die meiste
Zeit verbraten wird und sehen was man da optimieren kann.
Ich hatte auf dem Original System eine Zeitmessung mit einem freien
Timer gemacht, mal sehen vielleicht stelle ich den auf einen festen 1us
Takt und setze mal eigene Zähl Funktionen in den Code rein. Also eine
eigene Art gprof, nur halt nicht in jeder Funktion.
Peter
Peter schrieb:> Habe gerade meinen Test 200.000 mal durchlaufen lassen und oh Wunder ich> habe tatsächlich 0,05sec gesamt Laufzeit.
Sei nicht geizig! Lass das Ding mal 'ne Minute laufen.
Bernd K. schrieb:> Versuchs doch mal mit nem sampling profiler, z.B. sowas Oprofile.
Oprofile baut doch auf Linux auf, oder? Ob Peter das jetzt auf einem DOS
Profiler oder auf Linux macht ist IMHO egal.
Peter schrieb
> Ich hatte auf dem Original System eine Zeitmessung mit einem freien> Timer gemacht...
Halte ich für besser.
Wenn Du es geschickt per Makros aufaust, kannst du es per
Compilerschalter ein/ausschalten und die Zeitmessung so im Code
belassen.
Außerdem kannst Du gleich einen Maximalwert Speicher einbauen und
bekommst den Worst-Case Fall.
Konrad S.schrieb
> Sei nicht geizig! Lass das Ding mal 'ne Minute laufen.
Na wenn schon dann klotzen statt kleckern:
starten und Mittag machen... oder lass es über Nacht laufen...
wetten, dass sich die jetzigen 0.05 nochmals ändern...
Linux wäre auch kein Problem aber bei mir läuft alles unter Windows
außer Test VM-Ware Geschichten.
Habe es inzwischen einige Millionen mal laufen lassen und kann schon
etwas besser abschätzen wo es kneift.
Bin meinem Ziel von 1,4999ms schon näher gekommen (1,5783ms).
Auf die Stellen wäre ich ohne Gprof nie gekommen!
Einen eigenen fest eingebauten Profiler habe ich aber auch schon
vorbereitet.
Ist wie vorgeschlagen mit 2 Makros (IN /OUT) gemacht.
Klar wäre es noch besser ein Makro was die Funktion selber aufruft, aber
den Code wollte ich noch lesen können.
Dem Timer habe ich übrigens frei laufen und werte den Timerstand aus.
Solange nichts zu lange braucht und der Timer den Startwert überläuft
ist alles sauber.
Logischerweise braucht das mehr Laufzeit, aber im Release ist es ja aus!
Mal sehen ob ich damit noch die letzten Probleme finde.
Sollten ja jetzt mehr die Compiler und System Unterschiede dabei raus
kommen.
