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.
Was spricht dagegen, den relevanten Code in einer Schleife so oft aufzurufen bis die gemessenen Zeiten aussagekräftig werden?
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...)
Sieht mir nicht danach aus, denn wenn er es lange genug laufen lassen hätte, dann hätte er brauchbare Werte bekommen.
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.
Versuchs doch mal mit nem sampling profiler, z.B. sowas Oprofile.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.