1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

gcc bug verursacht Instabilitäten im Programm

Dieses Thema im Forum "OS X-Developer" wurde erstellt von jams, 18.07.09.

  1. jams

    jams Erdapfel

    Dabei seit:
    14.01.09
    Beiträge:
    5
    Hey zusammen,

    dies ist hier nun also mein erster Beitrag ;) Meist reicht mir die Lektüre anderer Threads. Dieses Mal nicht. Ich habe ein riesiges Problem. Ich würde euch zum einen um direkte Hilfe bitten, aber auch um Tipps, wie ich damit umgehen soll/ wo ich Hilfe bekommen kann.
    Los geht es.

    Ausgangssituation:

    Ich arbeite mit meinem Mac an einem numerischen Simulationsprogramm (Lösung der Einsteinschen Feldgleichungen in vereinfachter Form). Dazu benutze ich C und den gcc Compiler von Apple. In meinem Code ist nichts weiter schlimmes enthalten, lediglich dyn. Variablendeklarationen, Aufrufe von Unterfunktionen, Dateiausgabe, simple mathematische Kalkulationen. Zur Lösung meines Problems benutze ich das Runge-Kutta-Verfahren 4. Stufe.

    Mein Problem:

    Mein Programm arbeitet compilerabhängig stabil bzw. instabil. Ich musste feststellen, dass mein Programm bei einer 3.x.x gcc Version auf Linux Redhat instabil war. Seit gcc 4.x.x läuft es allerdings über mehrere tausend Iterationsschritte stabil. Das gleiche Ergebnis ergab sich auf verschiedenen anderen Linux Plattformen (z.B. ubuntu). Andere Studenten hatten dasselbe Problem. Offenbar war ein Bug im gcc, der in Version 4 behoben worden ist.
    Nun zu meinem Mac. Egal, ob ich die gcc version 4.0.1 oder die neuere 4.2.1 benutze, bleibt mein Programm instabil (heißt, es macht nach wenigen Iterationsschritten nicht mehr, was es soll). Es scheint also so, als hätte Apple die bug-fixes nicht alle übernommen?

    Lösung?:

    Natürlich habe ich keinen blassen Schimmer, was für ein Bug das im Compiler gewesen sein könnte. Fakt ist, dass er bei den mir zugänglichen Linux-Versionen ab Version 4 behoben wurde, beim Apple gcc 4 allerdings nicht.
    Kann mir da irgendjemand helfen? Hat jemand vielleicht ähnliche Probleme? Ich kann mein MacBook sozusagen in den Schrank stellen (oder Linux dazu installieren), weil mein kompletter Arbeitsalltag vom gcc abhängt.
    Bringt das was bei Apple anzurufen? Und über einen Fehler zu berichten, von dem ich nicht mal weiß, wie er heißt?

    Ich danke jedem, der sich dem Problem annimmt! :)

    Gruß
    Jochen


    Wichtige Daten:
    MacBook White, Summer 2008 (Intel Core 2 Duo 2.4 GHz, 4GB Ram)
    Mac OS 10.5.7.
    XCode 3.1.3
    gcc version 4.0.1 (Apple Inc. build 5493)
    gcc version 4.2.1 (Apple Inc. build 5574)
     
  2. below

    below Kalterer Böhmer

    Dabei seit:
    08.10.06
    Beiträge:
    2.865
    Es wäre natürlich gut zu wissen, welches Problem das war.

    Unabhängig davon solltst Du das Problem unter http://bugreport.apple.com einstellen. Das hilft Dir zwar kurzfristig nicht, ist aber trotzdem eine gute Idee.

    Falls Du Zugang zu seeds hast, kannst Du ja mal llvm ausprobieren. Vielleicht hilft das.

    Alex
     
  3. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    Wurden denn besondere Compileroptionen benutzt, z.B. -O3 oder -ffast-math? Damit habe ich auch schonmal Stabilitätsprobleme gehabt, besonders bei -O3 und dynamischen Datenstrukturen.

    Edit: Instabilitäten können natürlich auch vom mathematischen Approximationsverfahren selbst kommen. Die Runge-Kutta-Methode ist zum Beispiel als explizites Integrationsverfahren nur für nichtsteife Probleme geeignet, ansonsten wird es für vernünftige Schrittweiten instabil. Welche genaue Form hat Dein zu lösendes Differentialgleichungssystem?
     
    #3 quarx, 18.07.09
    Zuletzt bearbeitet: 18.07.09
  4. jams

    jams Erdapfel

    Dabei seit:
    14.01.09
    Beiträge:
    5
    Also, zunächst einmal benutze ich keine Compilerzusätze, wie -O3 oder andere Optimierungen etc.

    Zum Code: Ich löse die ADM-Gleichungen (3+1-Zerlegung der Feldgleichungen). Zu lösen sind dann gewöhnliche gekoppelte DGls 1. Ordnung der Form dy/dt = f(y,...).
    Das ganze ist tatsächlich hochgradig instabil für allgemeine Probleme. ABER für meine speziellen Anfangsbedingungen (flacher Raum) ist das Problem stabil. Und tatsächlich wird das ja durch die Linux Versionen (ab 4) von gcc bestätigt (Getestet habe ich 10000 Iterationsschritte, wohingegen beim Apple gcc nach max. 60 Schritten Schluss ist.).
     
  5. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    Ok. Ist das Problem denn steif, d.h. wie sieht die Jacobimatrix von f nach y aus? Was meinst Du genau mit "Iterationsschritt", führst Du etwa drumherum noch Newton-Schritte aus oder Ähnliches? Was ist das Abbruchkriterium?

    Und unter Linux, arbeitest Du da mit einem 32Bit- oder 64Bit-System?

    Edit: Es kann natürlich sein, dass der Apple-Compiler die Bugfixes nicht enthält. Dann solltest Du die melden. Du kannst Dir aber jederzeit von gnu.org die aktuelle Compilerversion herunterladen und den Compiler selbst bauen.
     
  6. jams

    jams Erdapfel

    Dabei seit:
    14.01.09
    Beiträge:
    5
    Mein DGl-System ist nicht steif, ich nutze keine Newton-Schritte. Mit "Iterationsschritte" meinte ich die Schritte, wie oft Runge-Kutta wiederholt wird, also einfach wie viele Schritte numerisch berechnet werden (in meinem Fall sind es Zeitschritte).
    Die mit Linux bestückten Rechner arbeiten mit 32 Bit.
    Ich würde mir gern meinen gcc mit den Paketen von gcc.gnu.org selber "basteln", dummerweise weiß ich (noch) nicht so recht, wie ich das machen muss. ^^
     
  7. karolherbst

    karolherbst Danziger Kant

    Dabei seit:
    11.05.07
    Beiträge:
    3.878
    ich würde wie oben beschrieben den llvm-gcc 4.2 compiler ausprobieren, bei dem ist mir nämlich aufgefallen, dass ich bei Julia-Fraktal Berechnungen ca. 50% mehr Rechengeschwindigkeit hab. Vlt hilft das ja irgendwie, aber ich befürchte das da wohlmöglich was anderes hintersteckt, auch das mit 32-bit und 64-bit könnte das Problem sein, was ich aber tendenziell verneinen würde
     
  8. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    10000 Zeitschritte wären allerdings numerisch sowieso mit Vorsicht zu genießen, Stichwort Rundungsfehler. ;) Benutzt Du da keine Zeitschrittweitensteuerung?

    Im Prinzip so. Zum Testen kannst Du Dir den Compiler im Homeverzeichnis installieren, also die Option --prefix=$HOME beim configure-Aufruf setzen.
     

Diese Seite empfehlen