optimize_aop
— Überprüfen der Hardware bezüglich des Potentials zur automatischen
Operator-Parallelisierung.
optimize_aop( : : OperatorName, IconicType, FileName, GenParamName, GenParamValue : )
HALCON unterstützt die automatische Parallelisierung (AOP)
für eine Reihe von Operatoren. Mit optimize_aop
lässt sich eine
effiziente Ausführung der Parallelisierung unabhängig von der
Rechnerarchitektur gewährleisten. Daher können alle HALCON-Programme
ohne Anpassungen an die Multiprozessor-Hardware durch den Benutzer verwendet
werden, so dass der Benutzer leicht von dem Potential paralleler Hardware
profitiert. Standardmäßig verwendet HALCON einen Thread je Prozessor für die
AOP. Allerdings kann abhängig von der Datenmenge und den Parametern eines
Operators die Parallelisierung auf allen verfügbaren Threads zu überzogen
und ineffizient sein. optimize_aop
testet die parallele
Datenverarbeitung der Operatoren und optimiert die AOP hinsichtlich der
Threadanzahl. Hierfür wird jeder Operator überprüft, wie er sich auf Tupel-,
Kanal- oder Domain-Ebene parallelisieren lässt (die partielle Ebene wird
nicht betrachtet). Jeder dieser Operatoren wird mehrere Male ausgeführt -
sequentiell wie parallel - mit unterschiedlichen Eingabeparametern und
wechselnden Bildgrößen. Dadurch können Abhängigkeiten der Laufzeit
des Operators von Eingabeparametern und Parallelisierung ermittelt werden.
Dies kann bis zu einigen Stunden dauern, abhängig von den Parameterwerten
dieses Operators. Für eine korrekte Optimierung ist es wichtig, keine
anderen rechenintensiven Anwendungen gleichzeitig auf dem Rechner laufen zu
lassen, da dies die Zeitmessungen des Operators stark beeinflussen und zu
verfälschten Ergebnissen führen würde.
optimize_aop
sammelt eine Menge Informationen für die aktuelle
Rechnerarchitektur, die es HALCON im laufenden Betrieb ermöglicht die
automatische Parallelisierung zu optimieren. Dieses Wissen über die
Hardware kann in einer Binärdatei, gegeben durch FileName
,
abgespeichert werden und in zukünftigen HALCON-Anwendungen
wiederverwendet oder auf andere, ähnliche Rechner übertragen werden.
Wenn ein leerer String '' als Dateiname übergeben wird, speichert
optimize_aop
die gewonnenen Daten in die spezielle
HALCON-System-Datei '.aop_info' unter Linux/macOS im
HALCON-Installationsverzeichnis (siehe Umgebungsvariable $HALCONROOT)
oder unter Windows in das Datenverzeichnis für gemeinsame Anwendungen. Diese
Datei wird während der Initialisierungsphase beim Aufruf des ersten
HALCON-Operators automatisch ausgelesen. Es ist zu beachten, dass die
entsprechenden Zugriffsrechte für Lesen und Schreiben gesetzt sind.
optimize_aop
überprüft die entsprechenden Zugriffsrechte
vor dem Starten des Optimierungsprozesses und gibt im Falle des Scheiterns
einen entsprechenden Fehler zurück. Die geschriebene Datei kann durch den
Operator read_aop_knowledge
wieder gelesen werden.
Es ist ausreichend, optimize_aop
einmal auf jedem Rechner
auszuführen, auf dem die automatische Operator-Parallelisierung ausgeführt
werden soll. Jedoch sollte der Operator erneut gestartet werden, wenn
die Hardware des Rechners geändert wird, beispielsweise durch einen neue
CPU, einen neuen Speicher oder ein verändertes Betriebsystem. Es ist
notwendig optimize_aop
einmal für jede neue Laufzeitumgebung
auszuführen, da sich das Zeitverhalten von Operatoren geändert haben könnte.
Eine Veränderung der Laufzeitumgebung wird verursacht durch einen Wechsel
des Betriebsystems, wie zum Beispiel Windows auf Linux, durch
unterschiedliche HALCON-Architekturen, unterschiedliche HALCON-Varianten,
d.h. HALCON und HALCON XL, oder wenn einen neue HALCON-Version oder
-Revision aktualisiert wird. Diese Hardwareabhängigkeiten werden zusammen
mit dem Computernamen gemeinsam mit den AOP-Optimierungsdaten in der Datei
gespeichert. Diese Attribute ordnen einen gespeicherten AOP-Datensatz einem
speziellen Recher zu und ermöglichen somit, dass AOP-Datensätze von
unterschiedlichen Rechnern in der selben Datei gespeichert werden.
optimize_aop
unterstützt einen Reihe von Parametern, um das
Verhalten der Optimierung zu beeinflussen. Eine Auswahl von Operatornamen
kann dem Parameter OperatorName
übergeben werden.
Dadurch lässt sich der Optimierungsprozess beispielsweise auf Operatoren
mit problematischen Laufzeitverhalten beschränken. Wird ein leerer String
'' übergeben, werden alle Operatoren getestet. Der Testumfang von
ikonischen Typen kann mit Hilfe des Parameters IconicType
eingeschränkt werden. Der leere String '' bewirkt, dass alle
unterstützten ikonischen Typen eines Operators getestet werden. Zusätzlich
kann der Optimierungsprozess mit Hilfe des
Parameterpaares GenParamName
und GenParamValue
beeinflusst
werden. GenParamName
definiert dabei den Parameternamen, während
GenParamValue
den jeweiligen Wert spezifiziert, so dass übergebene
Tupel bei beiden Parametern die gleiche Länge haben müssen. Im Folgenden
sind für alle Parameternamen von GenParamName
alle
unterstützten Parameterwerte von GenParamValue
beschrieben:
für GenParamName
hat keine Funktion,
ignoriert aber den Parameter GenParamValue
.
setzen jeweils die Art und Weise, wie die Informationen im HALCON-System b.z.w. der Datei aktualisiert werden sollen.
für GenParamValue
löscht alle
bestehenden Informationen, bevor das neue Wissen hinzugefügt wird.
überschreibt bestehendes Wissen und fügt neues hinzu (Standard).
belässt bestehendes Operatorwissen und fügt ausschließlich Wissen hinzu, das noch nicht enthalten ist.
führt den Optimierungsprozess durch, unterdrückt jedoch die Aktualisierung des Systems b.z.w. der Datei.
testet auch laufzeitrelevante Parameter
des entsprechenden Operators, falls der korrespondierende Wert
in GenParamValue
auf 'true' gesetzt ist.
Es werden Parameter berücksichtig, die bedeutenden
Einfluss auf die Laufzeit haben, wie beispielsweise Parameter, die eine
Methode oder einen Mode des Operators die Größe eines Filters setzen.
'false' unterdrückt die Überprüfung der Parameter zu Gunsten
eines schnelleren Optimierungsprozesses (Standard).
Setzt das zugrunde liegende Modell vom
Laufzeitverhalten des parallelisierten Operators auf der aktuellen
Hardware. Die Modelle, die durch den Parameter GenParamValue
ausgewählt werden, unterscheiden sich in ihrer Adaptionsfähigkeit an
Hardwareeigenheiten und dem Rechenaufwand sie zu bestimmen:
ermittelt für einen Operator, ob es sich rentiert, ihn auf der maximalen Threadanzahl zu parallelisieren. Dieses Modell ist standardmäßig auf Dual-Prozessor-Systemen eingestellt.
spezifiziert ein lineares Skalierungsmodell, um die effizienteste Threadanzahl für einen Operator mit einer gegebene Datenmenge und Parametersatz. Dies ist der Standard auf Multi-Prozessor-Systemen.
ist das komplexeste, aber auch das anpassungsfähigste Model. Der Optimierungsprozess kann allerdings abhängig von der verwendeten Hardware einige Stunden dauern.
setzt die maximale Ausführungszeit für einen
Testoperator. Falls die Laufzeitmessung eines Operators den Timeout
überschreitet, wird der Test des Operators abgebrochen.
In diesem Fall werden keine Informationen über diesen Operator
gespeichert. Der Timeout wird durch GenParamValue
in Sekunden
definiert. Der Wert 'infinite' verhindert den Abbruch des
Optimierungsprozesses eines Operators (Standard).
beschränkt den Optimierungsprozess auf
eine bestimmte Parallelisierungsmethode. Der entsprechende Wert in
GenParamValue
kann einen der folgenden Werte annehmen:
führt die Optimierung auf allen bildverarbeitenden Operatoren durch, die eine Datenparallelisierung auf Domainebene unterstützen.
führt die Optimierung auf allen bildverarbeitenden Operatoren durch, die eine Datenparallelisierung auf Kanalebene unterstützen.
führt die Optimierung auf allen bildverarbeitenden Operatoren durch, die eine Datenparallelisierung auf Tupelebene unterstützen.
Während der Tests muss optimize_aop
jeden zu optimierenden Operator
mehrere Male aufrufen. Abhängig von den Parameterwerten kann daher die
Ausführzeit von optimize_aop
sehr lang sein. Es ist daher für eine
korrekte Optimierung essentiell, keine weiteren rechenintensiven Anwendungen
gleichzeitig auf dem Rechner laufen zu lassen, da diese die Zeitmessungen
für die Optimierung deutlich beeinflussen und zu falschen Ergebnissen führen
würden.
optimize_aop
muss durch entsprechend autorisierte
Benutzer aufgerufen werden, damit die gesammelten Informationen
dauerhaft gespeichert werden können (Details hierzu finden sich
in der obigen Operatorbeschreibung).
OperatorName
(input_control) string(-array) →
(string)
Zu testende Operatoren.
Defaultwert: ''
IconicType
(input_control) string(-array) →
(string)
Zu testende Objekttypen.
Defaultwert: ''
Wertevorschläge: '' , 'byte' , 'int1' , 'int2' , 'uint2' , 'int4' , 'int8' , 'direction' , 'cyclic' , 'vector_field' , 'complex' , 'region' , 'xld' , 'xld_cont' , 'xld_poly'
FileName
(input_control) filename.write →
(string / integer)
Dateiname.
Defaultwert: ''
GenParamName
(input_control) string-array →
(string)
Parametername.
Defaultwert: 'none'
Wertevorschläge: 'parameters' , 'model' , 'timeout' , 'file_mode' , 'system_mode' , 'split_level'
GenParamValue
(input_control) string-array →
(string / real / integer)
Parameterwert.
Parameteranzahl: GenParamName == GenParamValue
Defaultwert: 'none'
Wertevorschläge: 'true' , 'renew' , 'truncate' , 'threshold' , 'linear' , 'mlp' , -1.0
Sind die Parameterwerte korrekt, dann liefert read_aop_knowledge
den Wert 2 (H_MSG_TRUE). Gegebenenfalls wird eine Fehlerbehandlung durchgeführt.
Foundation