"Programm-Bremse" gesucht

[taaktaak]

Hallo himitsu,
auf einen Beitrag von dir hatte ich gehofft. Nach dem Hinweis von s.h.a.r.k wäre es eigentlich besser, wenn man den Rechner (und damit alle übrigen Programme) nicht insgesamt ausbremst, sondern nur das eigene, zu testende Programm. Ist das nicht auch irgendwie möglich? Also mit einem als Bremse wirkenden "Nutzlos-Thread" innerhalb des Programms; diesen schaltet man dann je nach Bedarf ein/ab - oder ist das jetzt Unsinn??

//edit: Joo, Profiler, auch 'ne Idee.

// edit2:
...und lasse einen Thread in dem Programm möglichst viel Schwachsinn Produzieren...
JAAA, das ist meine Idee!! Wenn vielleicht jemand Lust hätte, so etwas - nur so zum Spass - zu coden.....
:love:

//edit3:
Da eigentlich nur das Programm selbst gebremst werden soll, werde ich den Titel mal ändern.

[rapante]

Du könntest dir auch mal Bochs anschauen - damit
lassen sich die verschiedensten Systeme emulieren.

[Namenloser]

Ich frage mich gerade, ob man so eine Programmbremse nicht über die Debugger-Schnittstelle programmieren könnte. Im Debugger ist es ja möglich, Breakpoints zu setzen, bzw. Code Stück für Stück auszuführen. Wenn man das automatisiert, also quasi automatisch den Code Zeile für Zeile ausführt, sollte man auf diese Weise das Programm auch ausbremsen können. Eventuell ist die Bremse allerdings zu stark, dann müsste man sich etwas einfallen lassen (z.B. größere Breakpoint-Abstände).

[Der.Kaktus]

hi taaktaak,

da gabs mal was..."alte Spiele" zum runter takten..kleines Tool..erinner mich da an "Digger"..kaum ne Taste angefasst...verloren...wenns mir wieder einfaellt, gebe ich Bescheid (dat waren Zeiten *schwaerm*).

[Medium]

Ich vermute, der Kaktus redet von DOSBox, was ein vollwertiger DOS Emu ist, und bei dem die Geschwindigkeit einfach anpassbar ist. Zum Win32 Anwendungen testen wäre das leider nicht brauchbar.

[Der.Kaktus]

Zitat:

Zitat von Medium

Ich vermute, der Kaktus redet von DOSBox, was ein vollwertiger DOS Emu ist, und bei dem die Geschwindigkeit einfach anpassbar ist. Zum Win32 Anwendungen testen wäre das leider nicht brauchbar.

nee nee :-D ...hab was gefunden --> CPU-Speed-Adjuster

[taaktaak]

Joo, habe die CPU-Bremse mal mit der Delphi-Sort-Thread-Demo ausprobiert: Keine Einstellung dieses Tools verändert (d.h. verlangsamt) die Ausführungsgeschwindigkeit dieses Demo-Programms in erkennbarer Weise.

Derzeit ist der "Nutzlos-Thread" mein gedanklicher Favorit...

[DeddyH]

[OT]

Zitat:

Zitat von taaktaak

Derzeit ist der "Nutzlos-Thread" mein gedanklicher Favorit...

Damit würdest Du Dich auch gut an das Forum anpassen, hier gibt es auch reichlich davon :mrgreen: (SCNR^^)[/OT]

[s.h.a.r.k]

Was soll denn so ein Thread bitte bringen? Ebenso planlos den Speicher zumüllen? Überlegt doch mal was bei "elementaren" Befehlen passiert? Die CPU führt diese ziemlich schnell aus, egal was nebenher passiert. Man hat heutzutage doch eh mind. einen Dual-Core, ergo ist das mit dem Thread eher planlos. Und da immer irgendwie was zu produzieren bringt wohl auch nichts, da der Zugriff auf RAM der zu 50% voll ist wohl genauso schnell ist, wie einer der nur zu 20% voll ist.

Zudem macht die Hardware die Geschwindigkeit beim Ausführen der Befehle aus und nicht. Wie willst du denn via Software Features einer CPU ausschalten, sodass man für nur ein Stück Software eine alte CPU vorgaukelt. Oder wie will man aus DDR2/3-RAM denn bitte SD-RAM machen?

[Medium]

Wenn ich das richtig verstanden habe s.h.a.r.k, geht es doch nicht um Kompatibilitätstests mit alter Hardware, sondern einfach darum das Programm beim debuggen auszubremsen, um Effekte sichtbar zu machen, die sonst einfach nur zu schnell wieder vom Auge verschwunden sind. Ich muss zwar zugeben diesen Wunsch bislang nie verspürt zu haben, aber vorstellen kann ich's mir schon :)

Dieser Slugger-Thread ist dennoch so eine Sache, eben N-Core vor allem, und überhaupt hat man damit schon arg wenig Kontrolle über das was das OS draus macht. Ich würde evtl. eher dazu übergehen zu entsprechenden Schlüsselpunkten programmgesteuert Screenshots zu speichern (das kostet sogar auch Zeit! ;) ). Also quasi ein visuelles Debug-Log.