Performance bei MI Aufrufen

[schatte]

Hallo Leute,

aktuell beschäftige ich mich mit der MI Programmierung. Dabei habe ich gelernt, dass man MI-Funktionen direkt aus ILE Cobol aufrufen kann. Auf diversen Webseiten wird berichtet, dass die MI-Aufrufe schneller sein sollen, als vergleichbare C-Funktionen.

Das habe ich nun auf meiner 170er (2292, V5R2) getestet und bin erstaunt, dass das Programm mit dem MI-Aufruf am meisten CPU benötigt.

Getestet habe ich die C-Funktion pow(), in MI die Funktion _POWER und in Cobol der Operator ** innerhalb einer COMPUTE Anweisung.

Hier die ILE Cobol Test-Sourcen:

IDENTIFICATION DIVISION.
PROGRAM-ID. CLCPOW.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 WERT-A COMP-2.
01 WERT-B COMP-2.
LINKAGE SECTION.
PROCEDURE DIVISION.
STEUER SECTION.
ANFANG.
MOVE 50 TO WERT-B.
PERFORM 999999 TIMES
MOVE 5000 TO WERT-A
COMPUTE WERT-A = WERT-A ** WERT-B
END-PERFORM.
ENDE.
GOBACK.



PROCESS NOMONOPRC.
IDENTIFICATION DIVISION.
PROGRAM-ID. CLCPOWC.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 WERT-A COMP-2.
01 WERT-B COMP-2.
LINKAGE SECTION.
PROCEDURE DIVISION.
STEUER SECTION.
ANFANG.
MOVE 50 TO WERT-B.
PERFORM 999999 TIMES
MOVE 5000 TO WERT-A
CALL PROCEDURE "pow" USING BY VALUE WERT-A
WERT-B
RETURNING WERT-A
END-CALL
END-PERFORM.
ENDE.
GOBACK.



PROCESS NOMONOPRC.
IDENTIFICATION DIVISION.
PROGRAM-ID. CLCPOWMI.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES. LINKAGE TYPE IS SYS FOR "_POWER".
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 WERT-A COMP-2.
01 WERT-B COMP-2.
LINKAGE SECTION.
PROCEDURE DIVISION.
STEUER SECTION.
ANFANG.
MOVE 50 TO WERT-B.
PERFORM 999999 TIMES
MOVE 5000 TO WERT-A
CALL "_POWER" USING BY VALUE WERT-A
WERT-B
RETURNING WERT-A
END-CALL
END-PERFORM.
ENDE.
GOBACK.


Hier die Auswertung eines Aufrufes als Batchjob. Verbrauchte CPU und Laufzeit per Accounting Journal QACGJRN ausgewertet:

<tbody>
Programm

CPU Zeit in Sek.

Dauer in Sek.



CLCPOW

2,350

2,582



CLCPOWC

4,145

4,335



CLCPOWMI

8,044

9,872


</tbody>

Kann mir jemand erklären, weshalb der MI Aufruf so langsam ist?

Viele Grüße
Matthias

[bateau]

Moien Matthias,

ist nur eine Vermutung und vielleicht sogar Nonsens (von daher möge man mich bitte ggf. berichtigen), aber ich vermute, dass es da einen Overhead beim Aufruf der MI Funktion aus der ILE Runtime heraus gibt.

Wir hatten dasselbe Spiel mal, als unser Pfeifendeckel-Softwarelieferant versucht hatte, die Performance seines in komplett monolithischem OPM Cobol geschriebenen Softwarepakets zu verbessern, indem er einfach nur diverse Programme 1:1 von OPM in ILE umgesetzt hat (also nur minimalste Code-Anpassungen, um das entsprechende Programm in ILE statt OPM compilieren zu können). Das hatte zur Folge, dass jedes Mal, wenn ein ILE Programm aus einem OPM Programm heraus per dynamischem Call aufgerufen wurde, die ILE Runtime aktiviert und initialisiert werden musste, insofern sie nicht schon im Call Stack vorhanden war => riesen Performanceeinbussen, klassisches Eigentor geschossen.

Ich vermute daher, dass etwas Ähnliches in deinem Beispielprogramm vonstatten geht. Sieht mir so aus, als würde da jedes Mal etwas für die Ausführung der MI Funktion initialisiert und danach wieder finalisiert/"zugemacht", d.h. es wäre in diesem Fall gar nicht die _POWER Funktion an sich, die langsam ist, sondern das Drumherum.

Änder mal zum Test dein Programm und schreib die Iteration der _POWER Funktion im aufgerufenen MI Programm statt im Cobol, dann wird mans ja sehen.

Grüsse

bateau

[schatte]

Hallo bateau,

danke für deine Antwort.
Bzgl. OPM -> ILE. Da wurde wohl beim Aufruf die Aktivierungsgruppe (z.B. QILE) erzeugt und beim Verlassen wieder aufgeräumt, da im Call Stack kein anderes Programm mit gleicher Aktivierungsgruppe vorhanden war.

Die Schleife in MI zu programmieren, ist mir im Moment noch nicht möglich. Allerdings wäre mir der direkte Aufruf aus Cobol auch lieber.

Schönen Sonntag noch.

Gruß
Matthias

[BenderD]

... bei der Benchmark ist nicht klar was sie eigentlich misst, da sie initialisierung und caching nicht korrekt abbildet. folgende Punkte würde ich ändern:
- die Schleife zweimal laufen lassen und nur die 2. Messung nehmen (damit sind die Initialisierungen sicher weg.
- statt fixe Werte random Werte potenzieren und zwar für alle 3 Varianten dieselben (gegen cahing Effekte)
- damit man nicht die random Funktion misst, in der Initialisierung ein Array mit random Werten füllen, anschließend darüber die Schleife jeweils mit allen 3 Methoden (damit dieselben Berechnungen gemacht werden mussen).
- letztlich noch die Reihenfolge der 3 Berechnungsmethoden variieren, um auszuschließen, dass einer den anderen schon konditioniert.
Das Ganze natürlich am Besten bei unbelasteter Maschine.

D*B

[Pikachu]

Falls es auch als OPM-COBOL-Programm geht, könntest du es mal mit CRTCBLPGM ... GENOPT(*XREF) wandeln und die erstellte MI-Quelle (in der Umwandlungsliste enthalten) untersuchen.

[Fuerchau]

Die Compiler erfinden ja auch nicht immer alles neu.
Bei OPM-Cobol mit der Option *LIST wird die MI-Auflösung angezeigt. Ggf. verwendet COBOL ja schon die MI-Anweisung:).

C-Funktionen kann man nur in ILE aufrufen, da gibt's aber kein MI-Listing mehr.
Sicherlich Erzeugst du Overhead beim Aufruf einer C-Funktion wobei die C-Funktion intern wohl wieder den MI-Befehl verwendet, die "MI-Funktion" wiederum ein Wrapper für den Aufruf des MI-Befehls ist.

[schatte]

Beim Ausführen von COMPUTE x = y**z. befindet sich im Aufrufstapel die Funktion CEESDXPD.

[Pikachu]

Etwas angepaßt und gewandelt als klassisches CBL steht in der MI-Umwandlungsliste, daß es die MI-Funktion CMF2 (http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/mi/CMF2.htm) mit Steueroperand X"0001" aufruft. (CMF2 .PFLANSW,X"0001",.PFLBASE,.PFLPOWR)

[schatte]

... bei der Benchmark ist nicht klar was sie eigentlich misst, da sie initialisierung und caching nicht korrekt abbildet. folgende Punkte würde ich ändern:
- die Schleife zweimal laufen lassen und nur die 2. Messung nehmen (damit sind die Initialisierungen sicher weg.
- statt fixe Werte random Werte potenzieren und zwar für alle 3 Varianten dieselben (gegen cahing Effekte)
- damit man nicht die random Funktion misst, in der Initialisierung ein Array mit random Werten füllen, anschließend darüber die Schleife jeweils mit allen 3 Methoden (damit dieselben Berechnungen gemacht werden mussen).
- letztlich noch die Reihenfolge der 3 Berechnungsmethoden variieren, um auszuschließen, dass einer den anderen schon konditioniert.
Das Ganze natürlich am Besten bei unbelasteter Maschine.

D*B

Mich interessiert schon die Gesamtzeit inkl. Initialisierung und nicht nur die Zeit innerhalb der Funktion. Dann scheidet der Aufruf direkt aus Cobol wohl aus. Also besser ein reines MI-Programm schreiben, dann wird man wohl die beste Performance erzielen können.

Danke für eure Antworten.

Schönen 1. Advent noch.

[BenderD]

... wenn der COBOL Compiler z.B.: vernünftig optimiert, dann merkt er, dass Du immer dieselben Werte multiplizierst und macht das genau 1 mal!!! Um nur einen der Pferdefüße an Deiner "Benchmark" zu benennen.