Floating Point Determinism - Brauche Eure Unterstützung beim testen



  • Hallo zusammen,

    ich arbeite zurzeit an einem Lock-step-Netzwerkmodell, d.h., dass nur Kommandos übertragen werden (z.B. Richtungswechsel), aber keine Positionsupdates usw..
    Das ganze basiert darauf, dass auf jedem Computer exakt die selben berechnungen durchgeführt werden.
    Dieses Prinzip wird von fast allen Realtime-Strategy-Games benutzt.
    Allerdings habe ich gelesen, dass es ein Problem mit Floating Point Determinismus gibt (mit verschiedenen CPUs und Einstellungen kommen wohl geringfügig unterschiedliche ergebnisse raus).
    Darüber kann man hier was lesen: http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/
    Dort werden auch Artikel verlinkt, in denen beschrieben wird, wie man die Berechnungen deterministisch(er) machen kann.

    Ich möchte das mit dem floating point determinismus testen. Dafür habe ich ein Programm geschrieben, dass 5 Sekunden lang eine Physiksimulation ausführt und dann eine CRC-Checksumme berechnet und ausgibt. Bisher habe ich keine speziellen Einstellungen oder Funktionen benutzt, um für Determinismus zu sorgen.
    Ich habe das ganze bisher auf 2 computern mehrfach getestet (beides Intel-CPUs) und immer kam die selbe CRC heraus.
    Ich möchte euch bitten, mir bei der Auswertung zu helfen. Ich lade die .exe Datei hoch (ja, erstmal nur für windows...) und ihr könnt sie dann ausführen und eure CRC-Summe hier posten.
    Das ganze baut übrigens auf der Physik-Engine Box2D auf. Damit wird also gleichzeitig noch die Determiniertheit von Box2D getestet.

    Also hier zum Download der .exe Datei (keine dlls werden benötigt): http://www.megaupload.com/?d=D66OEYSP

    Hier der source code:
    http://www.mediafire.com/?aiobb1c9lbz9bem

    Die CRC-Summe die bei mir heraus kommt ist übrigens die hier:
    4207241492

    Es wäre schon, wenn ihr eure CRCs hier postet, egal, ob sie gleich oder verschieden sind. Bitte schreibt auch eure CPUs dazu. Gut wäre, wenn jemand mit AMD-CPU das mal testen kann.

    Falls verschiedene Summen herrauskommen, werde ich eine neue Version herrausbringen und da funktionen einbauen, die floatingpoint-operationen deterministischer machen sollen (_controlfp(_PC_24, _MCW_PC) & co).

    Vielen Dank schonmal für eure Hilfe!



  • Bitte Source Code.

    Habe hier zB kein Windows, dabei hätte ich hier richtig schön viel Hardware zum testen...



  • Q6600 und Atom: Gleiche Prüfsumme.



  • cooky451 schrieb:

    Q6600 und Atom: Gleiche Prüfsumme.

    Danke fürs mitmachen! Mit intel siehts schonmal sehr gut aus!

    Shade Of Mine schrieb:

    Bitte Source Code.

    Habe hier zB kein Windows, dabei hätte ich hier richtig schön viel Hardware zum testen...

    Bitte sehr 🙂
    http://www.mediafire.com/?aiobb1c9lbz9bem

    Ein paar Anmerkungen:
    Ich hab die source dateien einfach aus dem visual studio projekt kopiert.
    Dort wurde ein precompiled header benutzt.
    Also einfach eine leere Datei mit namen stdafx.h erstellen, oder die includes davon rausnehmen.
    Außerdem falls dein Compiler kein #pragma once unterstützt, muss das durch include guards ersetze werden (wenn du wilslt sag mir einfach bescheid, dann kann ich das schnell machen).
    Außerdem brauchst du SFML 2.0 und box2D.
    Die Version von Box2d, die ich vewende habe ich vor ein paar Monaten kompiliert, also wenn du die neueste lädst kann es passieren, dass inkompatiblitäten auftreten.

    Das ganze wird dann ziemlich viel Arbeit für dich...
    Du musst dir das nicht unbedingt antun!

    Falls doch - schonmal ein dickes Danke!



  • Beim Athlon X2 stimmt die Prüfsumme ebenfalls überein.



  • AthlonUser schrieb:

    Beim Athlon X2 stimmt die Prüfsumme ebenfalls überein.

    Danke für die Teilnahme!
    Das sieht ja schonmal sehr gut aus!
    Ich habe nichts besonderes unternommen und trotzdem kriegt jeder das gleiche raus. In diversen Artikeln wurde aber immer wieder was anderes behauptet, also wärs gut wenn sich noch mehr Leute beteiligen um das zu verifizieren.
    Natürlich kanns auch ein Fehler im code sein, aber das halte ich für unwahrscheinlich.



  • Core i7 2600
    und
    Core2Duo T9600
    auch OK.

    PS:
    zuhause habe ich Windows und wenig Hardware. Morgen in der Arbeit mal schauen ob ich den Code kompiliert bekomme.



  • Jetzt doch unter windows?

    Anderes OS und/oder anderer compiler wäre auch mal interessant, aber ist nicht unbedingt eine Anforderung von mir, dass es damit läuft.
    Natürlich ist die Portierung einiges an Arbeit, weil man dann die bibliotheken noch kompilieren muss.

    Noch weitere AMD-Kandidaten vielleicht?



  • Mit Problemen rechne ich hier eher durch...
    * unterschiedliche Compiler
    * unterschiedliche Compiler-Flags
    * kleine Änderungen im Code, die dazu führen dass der Compiler anders optimiert

    Siehe z.B. http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

    GCC wird da aber u.U. andere Vorstellungen davon haben was gut und richtig ist.

    Was eine (x86 bzw. AMD64 kompatible) CPU zu tun hat, ist dagegen im IEEE 754 sehr genau definiert. D.h. wenn da was anders läuft, ist es ein Bug.

    Trotzdem würde ich persönlich ein "delta only" Modell mit float/double nicht machen wollen, wäre mir insgesamt zu riskant.



  • ~~Gerade hat ein Freund von mir getestet:
    AMD Atholon(tm) X2" Dual Core Processor 5000+ 2.60 GHz
    Ergebnis: 1385279624

    Also die erste CPU die "anders" ist...

    Ich werd dann mal die Funktionen verwenden die das ganze regulieren sollen und nochmal testen.~~

    Mir reicht es auch wenn das ganze nur mit einem compiler und OS benutzt wird, aber selbst das ist nicht ganz einfach wies aussieht...

    Edit: Entwarnung, er hatte ne falsche exe. Er kriegt auch die selbe zahl raus.



  • Ich verstehe das Problem nur teilweise und habe folgende Fragen:

    - In welchem Wertebereich sind die floating points?
    - Wieviele Nachkommastellen sind wichtig?
    - Kann man das zur Eindeutigkeit evtl. in integer umwandeln?



  • berniebutt schrieb:

    - In welchem Wertebereich sind die floating points?

    Theoretisch ist der volle wertebereich möglich. Wieviel im moment von der physics engine genutzt wird - gute frage.

    berniebutt schrieb:

    - Wieviele Nachkommastellen sind wichtig?

    Alle! Wenn nur 1 bit kippt kann das auf dauer zu starken veränderungen führen (Chaos Theory :D) und außerdem ist die checksumme dann direkt falsch

    berniebutt schrieb:

    - Kann man das zur Eindeutigkeit evtl. in integer umwandeln?

    Dann müsste man die ganze physics engine umschreiben und ich denke nicht das das sinnvoll ist. Außerdem will ich auch selbst floating point zahlen benutzen.

    Edit: Das auf der letzten Seite war ne falschmeldung, ich hatte ihm ne falsche exe geschickt, deswegen war die nummer falsch gewesen.
    Bisher hat also noch jeder das selbe rausbekommen.

    hustbaer schrieb:

    Was eine (x86 bzw. AMD64 kompatible) CPU zu tun hat, ist dagegen im IEEE 754 sehr genau definiert. D.h. wenn da was anders läuft, ist es ein Bug.

    Der standard schreibt es vielleicht sehr genau vor, das heißt aber nicht das sich alle genau dran halten.

    Z.B. benutzt intel 80 bit register zum rechnen mit floating points, amd nur 64. Das allein kann schon für Probleme sorgen. Glücklicherweise scheints aber bisher überall gut zu gehen.

    Wenn noch weitere Tests gemacht werden wäre das natürlich sehr gut 🙂


  • Mod

    Q schrieb:

    Alle! Wenn nur 1 bit kippt kann das auf dauer zu starken veränderungen führen (Chaos Theory :D) und außerdem ist die checksumme dann direkt falsch

    Ich habe jetzt nicht den Thread gelesen, aber wenn du Chaos hast, kannst du mit Fließkommazahlen sowieso nichts exaktes bekommen, weil diese auch endlich sind. Eigentlich kann dir ein Computer überhaupt nicht helfen.



  • CRC: 4207241492. Getestet mit einem Core i7 2720QM auf einem virtuellen Windows 7 x64. Da kommt nichts anderes raus, egal was man probiert.

    Kann man sowas eventuell auch auf einem ARM zum laufen bringen? Wenn jemand das Zeug für Android kompilieren mag, habe ich hier noch einen Snapdragon und einen Tegra 2.



  • SeppJ schrieb:

    Q schrieb:

    Alle! Wenn nur 1 bit kippt kann das auf dauer zu starken veränderungen führen (Chaos Theory :D) und außerdem ist die checksumme dann direkt falsch

    Ich habe jetzt nicht den Thread gelesen, aber wenn du Chaos hast, kannst du mit Fließkommazahlen sowieso nichts exaktes bekommen, weil diese auch endlich sind. Eigentlich kann dir ein Computer überhaupt nicht helfen.

    Es geht nicht um die Genauigkeit der Ergebnisse, sondern um die Reproduzierbarkeit. Bei den selben Rechnungen muss auf mehreren verschiedenen Computern immer das selbe rauskommen. Darum geht es.

    /rant/ schrieb:

    CRC: 4207241492. Getestet mit einem Core i7 2720QM auf einem virtuellen Windows 7 x64. Da kommt nichts anderes raus, egal was man probiert.

    Kann man sowas eventuell auch auf einem ARM zum laufen bringen? Wenn jemand das Zeug für Android kompilieren mag, habe ich hier noch einen Snapdragon und einen Tegra 2.

    Gut zu hören! Auch danke für die Teilnahme!

    Bisher wurde erst 2 mal AMD getestet, wäre gut, wenn sich da noch was tut 🙂



  • Habs gerade auf nem Intel Core i5 650 (W7, 64 Bit) und auf nem AMD Athlon 64 3500+ (XP, 32 Bit) getestet. Hatte auch beide Male 4207241492.


Log in to reply