Performance bei MI Aufrufen

[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 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.

[Fuerchau]

Wie das halt immer so ist.
Beim OPM wird direkt der MI-Befehl verwendet, bei ILE scheint eine MATH-Bibliothek verwendet zu werden.
Jeder Compiler löst das nun auf seine Weise.
Reines MI geht für solche Aktionen natürlich immer, zumal ein CALLX (Externer Call) fast so schnell wie ein GOTO ist.
Bedenke aber, nicht jeder kann MI und es gibt nur einen OPM-MI-Compiler.