Ich hab ein kleines schachartiges Programm geschrieben.

Dabei ist mir auf aufgefallen, dass das Programm sich in der Suchroutine anders verhält wenn ich die Delphioptimierung beim compilieren anschalte, als wenn ich diese auslasse.

Dabei ist das Verhalten jeweils reproduzierbar, sowohl die optimierte als auch die unoptimierte Suchfunktion erzielt für sich immer die selben Suchergebnisse. Allerdings unterscheiden sie sich zum Teil recht heftig Das geht soweit, dass die eine Version einen anderen Zugvorschlag macht als die andere Das ist natürlich nicht schön, vor allem, weil die optimierte zwar ab und an extrem schneller ist aber dann einfach ganz schlechte Züge macht, Matts nicht findet usw.

Da das Debuggen recht aufwändig ist (oft werden Millionen von Stellungen in einer rekursiven AlphaBeta-Suche erzeugt) und in Verbindung mit dem Optimizer eh nicht gescheit funktioniert wollt ich mal ein paar Tipps haben auf was ich im Code speziell achten sollte, welche Teile von Optimierer vor allem bearbeitet werden und für das "Fehlverhalten" verantwortlich sein könnten. Denn den Geschwindigkeitsgewinn würd ich schon gerne mitnehmen, es ist schon ein Unterschied ob 100.000 oder 400.000 Stellungen in der Sekunde bearbeitet werden ;)


Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Do 01.07.2010 um 09:51

Verwendest du irgendwelche Schleifenvariablen nach der Schleife noch?
Da sollte dann eigentlich ne Warnung kommen, dass der Wert undefiniert ist.

Kommen denn Warnungen/Hinweise oder so?

Sagt Dir der Compiler IRGENDWELCHE Warnungen in der Unit an? Wenn ja: Hebeb erstmal ALLE davon und versuch dann noch mal. Insbesondere Schleifenvariablen, uninitialisierte Variablen, und der Gleichen, erzeugen gerne solche Effekte.

Verwendest Du Threads? Weil die Optimierung beeinflusst das Zeitverhalten und kann damit auch ähnliche Effekte bei schlechter Synchronisation von Threads erzeugen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hats getroffen. Ich verwende viele "Case of"-Konstrukte, diese werden alle (ob zurecht oder nicht) mit Warnings belegt, dass irgendwelche Vars eventuell nicht initialisiert sind. Und in der Tat hatte der Compiler einmal recht, da ist mir was durchgerutscht. Scheinbar nullt der Compiler bei Nichtinitialisierung die Variable wenn Optimierung aus ist. Ist sie an, dann steht da ein Zufallswert drin.

Bin mir nicht sicher ob "Delphioptimierung" Auswirkung auf das Problem hat, welches ich einmal hatte.

Früher konnte man mit Compilerschaltern das Ausführen von Funktionen wie folgt verändern:

Beispiel:
BollscheVariable:=Funktionsergebnis1 OR Funktionsergebnis2

Normal:

Beide Funktionen werden ausgeführt.

Optimiert:

wenn Funktionsergebnis1 = 1 dann wird Funktion 2 gar nicht erst ausgeführt.

Wenn in Funktion 2 nebenbei etwas gemacht wird, was immer ausgeführt werden soll, klappt das nicht.

Da kommt man auch nicht so schnell darauf

Das nennt sich "Vollständige Auswertung Bolleanscher Ausdrücke" und steht als ein Optimierungsschritt immer noch zur Verfügung. Das ist auch ein Grund, warum Funktionen keine Nebeneffekte haben sollten.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.