simulation eines langsamen rechners



  • hallo,

    ich habe das problem, dass mein c++ programm auf meinem entwicklungsrechner stabiler läuft als auf einem anwendungsrechner. es ist zu umständlich, mein programm häufig auf dem anwendungsrechner neu zu installieren um verbesserungen zu testen.
    kann ich irgendwie auf dem entwicklungsrechner die leistung des anwendungsrechners simulieren? am optimalsten wäre eine drosselung nur für mein programm zum debuggen.

    entwicklungsrechner:
    i7-2760QM @ 2,4GHz
    16GB RAM
    Win7 Enterprise

    anwendungsrechner:
    core2duo @ 2,0 GHz
    2GB RAM
    WinXP Professional

    Danke!



  • Wäre es nicht sinnvoller zu schauen, warum das Programm "instabil" und scheinbar abhängig von der Leistung des Rechners ist? Vielleicht liegt es ja auch gar nicht an der Leistung (ist bislang nur eine Vermutung, oder?). Ich würde mal eine ausgiebige Remote Debugging Session empfehlen. Vielleicht kannst du den Fehler ja lokalisieren und dafür sorgen, dass dein Programm stabil ist, unabhängig vom verwendeten Rechner.



  • ja, danke, remote debugging ist natürlich eine option. ich wäre aber gerne unabhängig vom anwendungsrechner, da ich öfter mal unterwegs programmiere bzw an unterschiedlichen standorten.


  • Mod

    mael15 schrieb:

    ich wäre aber gerne unabhängig vom anwendungsrechner, da ich öfter mal unterwegs programmiere bzw an unterschiedlichen standorten.

    Gerade deswegen, wäre es doch angebracht, ein fehlerfreies Programm zu haben. Dein Fehler klingt von der Beschreibung her nach einer Racing Condition. Das ist nie richtig, du hast auf deinem Entwicklungsrechner bloß Glück.



  • ich denke auch, dass es eine racing condition ist. ich versuche auch schon mit mutexes und critical sections entgegen zu steuern, nur kann ich eben auf dem entwicklungsrechner schlecht feststellen, ob ich das problem behoben habe, weil das programm dort nicht abstürzt. deswegen brauche ich ja die drosselung der leistung, damit abstürze auftreten wenn das problem immer noch nicht behoben ist.

    also scheint es keine brauchbare möglichkeit zu geben, die leistung des entwicklungsrechners der des anwendungsrechners anzupassen?



  • Sicher, das es an der Geschwindigkeit liegt?
    Es kann auch an mangelnden Resourcen liegen.

    Mach doch eine Virtuelle Maschine.



  • Um was für ein Programm handelt es sich denn?



  • Würde ich auch sagen: virtuelle Maschine aufsetzen. Die kannst Du ja beliebig runterdrosseln...

    Btw: das ist ein altes Lied schon seit Uhrzeiten... die Entwickler haben immer Powermaschinen und bemerken nie, was der Anwender für ein Leid zu tragen hat auf seinem System. Am besten auch noch 1GBit-Anbindung an den Server. Und der Anwender mit seiner GPRS-Verbindung wundert sich dann über die lahme Reaktion seines Programms...



  • Hi,

    ich hab für die Anwendungen die ich an die Nutzer Rausgebe noch einen steinalten Laptop mit Win-XP und 64 MByte Hauptspeicher (nicht verlesen, wirklich 64 MB) und erst wenn ein Programm auch darauf noch läuft gebe ich es raus.
    Man glaubt gar nicht, wie viele noch mit solchen alten Möhren arbeiten. Da ist es gut, noch so ne Kiste da zu haben um das vorher zu testen.

    Gruß Mümmel



  • danke für eure vielen anregungen!

    DirkB schrieb:

    Sicher, das es an der Geschwindigkeit liegt?
    Es kann auch an mangelnden Resourcen liegen.
    Mach doch eine Virtuelle Maschine.

    mangelnde resourcen würden auch infrage kommen, eine virtuelle maschine werden ich mal versuchen.

    pyhax schrieb:

    Um was für ein Programm handelt es sich denn?

    das programm sammelt daten über einen a/d wandler von national instruments, speichert sie in einem buffer und stellt sie dann auf dem bildschirm dar. da das mit unterschiedlichen threads läuft könnte es dabei zu einer race condition kommen, ich prüfe das gerade.

    muemmel schrieb:

    Man glaubt gar nicht, wie viele noch mit solchen alten Möhren arbeiten. Da ist es gut, noch so ne Kiste da zu haben um das vorher zu testen.

    die problematik war mir bisher neu, weil ich nur zum firmeninternen einsatz programmiere und auch die einsatzrechner alle kenne. aber irgendwann soll mein programm auch in die weite welt, dafür werde ich wohl in zukunft auch immer auf minimalen rechnern testen.

    danke!



  • ich erstelle dazu ein paar threads die nur loopen, alle threads (sammt main thread) werden per thread affinity mask an einen core gebunden und dann laeuft dieses eine program langsam.



  • Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt. 😉



  • Du kannst ja auch mal den ApplicationVerifier ausprobieren. Der kann soweit wie ich weis eine Low Resource Simulation machen und dabei gleichzeitig auf Fehler (Locks, ...) prüfen.



  • Bitte ein Bit schrieb:

    Du kannst ja auch mal den ApplicationVerifier ausprobieren. Der kann soweit wie ich weis eine Low Resource Simulation machen und dabei gleichzeitig auf Fehler (Locks, ...) prüfen.

    gute idee! leider startet mein programm dann garnicht mehr und beim debuggen wird keine stelle meines quellcodes ausgegeben.

    Dobi schrieb:

    Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt. 😉

    ich kann dir leider nicht ganz folgen. schnelles googeln hat mich auch nciht weiter gebracht. hast du einen link, damit ich mich darin einlesen kann?



  • Dranbleiben !

    Konfiguriere den Application Verifier mal nur mit den Standardeinstellungen und überprüfe damit deine Debug-Version. Starte dein Program aus der IDE (hoffentlich VS) heraus. Sollte nun irgentein Absturz erfolgen, wird die IDE direkt an die Stelle springen, bloß du musst dazu nur den richtigen Thread finden, denn offenbar laufen gerne andere Threads in einem Program, ohne das man diese selbst programmiert hätte.



  • yo, ich programmiere mit vsPro.
    wenn ich auch noch alle basic test ausschalte, dann startet das programm tatsächlich. nur ist der output leider bei jedem crash ein anderer.

    ich verstehe nicht, was du damit meinst:

    Bitte ein Bit schrieb:

    bloß du musst dazu nur den richtigen Thread finden

    alternativ bin ich noch gerade dabei, virtual pc für mein programm einzurichten. dort kann ich dann zumindest die größe des RAM einstellen. kann ich im application verifier noch finetunen, was mit "low resource simulation" genau gemeint ist?



  • mael15 schrieb:

    Dobi schrieb:

    Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt. 😉

    ich kann dir leider nicht ganz folgen. schnelles googeln hat mich auch nciht weiter gebracht. hast du einen link, damit ich mich darin einlesen kann?

    http://www.c-plusplus.net/forum/261827
    Das kannst du dir ja auch hübsch irgendwo hinpacken, damit du es in verschiedenen Programmen wiederverwenden kannst. Zum Testen schreibst du am besten etwas, das absichtlich scheppert und schaust an, ob du mit dem dadurch entstandenen dump und deinem Debugger etwas anfangen kannst. Vor zwei Wochen hab ich mit der Methode nen Bug in einem uralten (leider auch großen und chaotischen) Programm von uns gefunden, der natürlich nur beim Kunden und auch nur bei einem speziellen auftauchte. Am Ende wars dann auch ein Sync-Fehler zwischen zwei Threads, wodurch einer dann mit nem Zeiger rumhantiert hat, der irgendwo ins Nirvana schaute.



  • mael15 schrieb:

    Dobi schrieb:

    Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt. 😉

    ich kann dir leider nicht ganz folgen. schnelles googeln hat mich auch nciht weiter gebracht. hast du einen link, damit ich mich darin einlesen kann?

    http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu

    Die dort enthaltenen Infos/Tips wie man es macht zum Debuggen die passenden .pdb Files zur Verfügung zu haben finde ich allerdings nicht gut.
    Dafür gibt es Source Server/Symbol Server.



  • Die pdbs müssen doch nicht beim Kunden liegen. Ich hab mir die einfach zusammen mit der Exe und den Sourcen vom Zeitpunkt, an dem ich die core-dump-schreibende Version kompiliert hab, irgendwo hinkopieren und wieder ausgraben als der Dump da war. Ab da waren es dann ja nur noch drei Klicks.



  • danke dobi und hustbaer, die beiden links habe ich kurz überflogen und sie sehen sehr vielversprechend aus. umsetzen werde ich das auf jeden fall nächsten montag. schönes wochenende!



  • Dobi schrieb:

    Die pdbs müssen doch nicht beim Kunden liegen.

    Hat denn jemand behauptet dass die beim Kunden liegen müssten?


Anmelden zum Antworten