Assoziativität bei Programmen
-
Die Fließkommazahlen sind nicht geschlossen.
Dass heisst es herrscht keine Assozivität wie bei den reelen Zahlen.
Reele Zahl != Fließkommazahl nach IEE 754
Da darf mann wenn man es ernst nicht auch nicht mal so etwas vergleichen
a+b+c = a+(b+c)Ist leider ein häufiger Fehler bei Programmen.
Erst recht nicht wenn man mit Threads arbeitet!!!!
-
Wir sprachen doch von Programmen, nicht von Computerprogrammen.
Was ist denn ein Programm im Vergleich zu einem Computerprogramm?
-
knivil schrieb:
Wir sprachen doch von Programmen, nicht von Computerprogrammen.
Was ist denn ein Programm im Vergleich zu einem Computerprogramm?
http://de.wikipedia.org/wiki/Programm
Vieles davon ist bestimmt nicht assoziativ. Außer Parteiprogrammen, die sind komplett austauschbar, ohne das sich was ändert
-
darkfate schrieb:
Reele Zahl != Fließkommazahl nach IEE 754
Da darf mann wenn man es ernst nicht auch nicht mal so etwas vergleichen
a+b+c = a+(b+c)Du und deine Fliesskommazahlen ... das gilt streng genommen auch nicht fuer ganze Zahlen mit fester Bitlaenge. Auch brauche ich keine Threads dafuer ins Boot holen.
PS: Weisst du, was man ueber Leute sagt, die drei oder mehr Ausrufezeichen benutzen?
-
knivil schrieb:
Du und deine Fliesskommazahlen ... das gilt streng genommen auch nicht fuer ganze Zahlen mit fester Bitlaenge. Auch brauche ich keine Threads dafuer ins Boot holen.
Bei int brauchst du mit a+b+c = a+(b+c) keine Sorgen haben solange kein Überlauf stattfindet.
Es geht allgemeinhin dazu dazu dass die Leute in den Compilern alle Optimierungen anschalten was zu Vektorisierung/Threads führt. So bauen man sich auch gleich unbeabsichtigte Fehler in seinen Code und weiß nicht woher er kommt.
knivil schrieb:
PS: Weisst du, was man ueber Leute sagt, die drei oder mehr Ausrufezeichen benutzen?
Muss man alle Bräuche aller Subkulturen wissen?
-
Bei int brauchst du mit a+b+c = a+(b+c) keine Sorgen haben solange kein Überlauf stattfindet.
Tja, aber genau das meinte ich mit "streng genommen". Oder wie garantierst du, dass kein Ueberlauf auftritt? Auch ist das nur ein Spezialfall von "Seiteneffekt".
Es geht allgemeinhin dazu dazu dass die Leute in den Compilern alle Optimierungen anschalten was zu Vektorisierung/Threads führt. So bauen man sich auch gleich unbeabsichtigte Fehler in seinen Code und weiß nicht woher er kommt.
Kannst du mal ein Beispiel posten. Mir ist das mit dem gcc (und -O3) noch nie passiert.
Muss man alle Bräuche aller Subkulturen wissen?
Es ist fast so beruehmt wie die Zahl 42.
-
knivil schrieb:
Kannst du mal ein Beispiel posten. Mir ist das mit dem gcc (und -O3) noch nie passiert.
Gerne: http://software.intel.com/en-us/articles/parallelization-and-floating-point-numbers/
Oder allgemein: http://software.intel.com/en-us/profile/336629/
Er zeigt viele Fehler auf die man meistens gar nicht selber entdeckt wenn man nicht explizit auf einen Fehler im Ergebnis stößt dass nicht auf den Code zurückzuführen ist.
knivil schrieb:
Es ist fast so beruehmt wie die Zahl 42.
Entschuldigung aber damit kann ich ebenfalls nichts anfangen.
-
darkfate schrieb:
knivil schrieb:
Es ist fast so beruehmt wie die Zahl 42.
Entschuldigung aber damit kann ich ebenfalls nichts anfangen.
Meine Güte, lernt man sowas nicht in der Schule?
http://de.wikipedia.org/wiki/42_(Antwort)
http://wiki.lspace.org/wiki/Multiple_exclamation_marks
-
Ich habe mal den Artikel durchgelesen:
This means that as you change the order of a long sequence of arithmetic operations, you can generate different answers.
Das ist allgemein bekannt. Summiert man Fliesskommazahlen im Computer, so sollte man bei der kleinsten beginnen zu addieren.
Note also that, with a serial algorithm, you’d never know there was a problem.
Das stimmt nicht. Nur gedankenlose Programmierer erkennen keine Probleme. Selbst bei Wikipedia findet sich eine breite Beschreibung http://en.wikipedia.org/wiki/Floating_point und dann gibt es immernoch den Klassiker What Every Computer Scientist Should Know About Floating-Point Arithmetic.
Was ich damit sagen will: Das Problem ist unabhaengig von Threads oder Compileroptimierungen.
-
SeppJ schrieb:
Meine Güte, lernt man sowas nicht in der Schule?
Das ist doch jetzt nicht dein Ernst.
knivil schrieb:
This means that as you change the order of a long sequence of arithmetic operations, you can generate different answers.
So ist es nicht gemeint. Er geht hier explizit auf das Threading-Problem ein. Du wirfst parallel IEE754 mit IEE754 zusammen. So wie du es herausziehst geht das nicht.
knivil schrieb:
Das stimmt nicht. Nur gedankenlose Programmierer erkennen keine Probleme. Selbst bei Wikipedia findet sich eine breite Beschreibung http://en.wikipedia.org/wiki/Floating_point und dann gibt es immernoch den Klassiker What Every Computer Scientist Should Know About Floating-Point Arithmetic.
-
Wenn du irgendwo in einem ernsten Vortrag Wikipedia zitierst steht mehr als die Hälfte auf und geht. Der Rest zitiert selber Wikipedia. Ausgenommen der Bilder ist Wikipedia einfach ein no-go. Es ist und bleibt ein unvollständiges und in vielen bereichen auf Schulwissen getrimmtes Lexikon für Arme, indem pubertierende Teenager sogar wissenschaftliche Beiträge löschen.
-
Dieser Mann arbeitet mehr als 20 Jahre im Bereich "Parallel Programming" als führende Rolle bei Intel. Er hat Bücher geschrieben und hält regelmäßig Vorträge. Nachdem ich mich über ein Jahr damit beschäftige kann ich diese Probleme bezeugen. Was für serielle Algorithmen einfach gilt, dafür muss man im parallelen dreifache Mühe investieren. Was du hier immer noch nicht trennst ist IEE754 und paralleles IEE754 und beides verhält sich eben anders. Obwohl die neuen Revisionen der Compiler mit OpenMP 3.0 und den restlichen Optimierungen deutlich besser geworden sind.
knivil schrieb:
Was ich damit sagen will: Das Problem ist unabhaengig von Threads oder Compileroptimierungen.
Dann hast du nichts von dem was der Kerl geschrieben hat verstanden.
Je höher der Grad der Optimierung ist, desto mehr läuft man in Gefahr automatische Vektorisierungen zu übersehen. Folglich: Desto mehr wirken sich diese Probleme aus.Übrigens: gcc -O3 vektorisiert ebenfalls
Was mir hierzu nur einfällt ist dass du bewusst versuchst mit irgendetwas aber hauptsache zu kontern, auch wenn es Unsinn ist, von daher erspare ich mir hier weitere Beiträge zu lesen.
Falls jemand dennoch am richtigen parallelen Programmieren ist, kann ich für Anfänger die keinen Start finden könnnen die Intel Ressources empfehlen. Der Intel Compiler für Linux ist für Übungszwecke und freie Software kostenlos. Damit kann man auch alle Beispiele durchgehen und die Problematik nachvollziehen.
-
-
knivil schrieb:
das gilt streng genommen auch nicht fuer ganze Zahlen mit fester Bitlaenge.
Nö da gilt das auch.
-
Es gilt nicht fuer alle a: (a * 2) / 2 = a * (2 / 2)
-
darkfate: Wenn ich das richtig sehe, geht es hier nicht um Threads an sich, sondern darum, dass sich die Reihenfolge der Operationen bei der Aufteilung(!) in Threads ändert. Der eine Thread rechnet quasi 1+3+5+...+9, der andere 2+4+...+10, und das Ergebnis ist anders als wenn man 1+2+3+...+9+10 gerechnet hätte. Das könnte man natürlich auch seriell simulieren.
Deine erste Äußerung dazu kam so rüber, als würden sich Fließkommaoperationen auf magische Weise anders verhalten, nur weil man irgendwo mit Threads arbeitet. Klar, dass du dafür Gegenwind kriegst.
-
knivil schrieb:
Es gilt nicht fuer alle a: (a * 2) / 2 = a * (2 / 2)
Du weißt aber schon was Assoziativität ist, oder?
Auf Ganzzahlen gibt es 2 assoziativ Gesetze:
a+(b+c) = (a+b)+c
a*(b*c) = (a*b)*c
Da kommt keine Division drin vor.
