Benchmark Power 9 vs Intel

[camouflage]

Hallo Kollegen,
Es ist eine Frage aufgetaucht, die ich so auch nicht beantworten kann, weil mir etwas technisches Verständnis dafür fehlt.

Und zwar hat ein MSoftie einen Prozessortest Intel mit folgendem Statement (analog RPG) gemacht.

for i = 1 to 1000000000; // 1 Mia
result = i/PI;
endfor;

Der Intel-Prozessor brauchte angeblich 3.5 Sekunden und die i9 über eine halbe Stunde.
Hat mir jemand dazu eine Erklärung.

Danke.

[Robi]

MS, Intel und Co
Rechenleistung für solche Spielereien

iSeries
Datenbank Rechner

Ein Kunde von uns hat mehrere Mio (komplexe) Datensätze gekauft.
Die eine hälfte hat die i in Ihre 'Berarbeitungssoftware übennommen, die andere hälfte wurde in das PC-System der Tochterfirma übernommen.
Die i war nach 5 Stunden fertig, das PC System nach 55 Stunden. 11 mal so lange!!

[Fuerchau]

Wieviele sonstige aktive Jobs und User ware auf der P9 und wieviele auf dem Intel aktiv?
Ein vergleichbarer Test wäre allenfalls auf einem Terminalserver sinnvoll.
Allerdings arbeitet Windows bzgl. des Multtaskings anders als die IBM i.
Fahr die P9 mal in den eingeschränkten Zustand ;-) und lass das Programm dann mal laufen.

Einzelne Tests losgelöster Ressourcen zu vergleichen sind da immer kontraproduktiv.
Die Gesamtumgebung ist da zusätzlich zu betrachten.

Auch der DB-Vergleich ist da nicht aussagefähig.
Bei der PC-Datenbank kommt es ebenso auf Multiprozessor-Features o.ä. an.
Auf der IBM i können Indexpflege und Bulkinserts durchaus parallel laufen, auf einem M$-SQL-Server ist das nur möglich, wenn man mehrere Tabellen füllt.
Füllt man per Bulkinsert nur 1 Tabelle geht dies nur sequentiell da eine Tabelle für eine Transaktion immer komplett gesperrt wird.
Nur wenn man Satzversionen einsetzt (kennt die DB2/i gar nicht), kann man auch Bulk-Inserts erheblich durch Parallelisierung beschleunigen.
Außer dem ist auch die Frage, ob bei dem PC-Test auch Bulk-Operationen eingesetzt wurden.

Fazit: immer vorsichtig mit Vergleichen.

[Rainer Ross]

Hallo Kollegen,

ich habe es auf meiner Power 7+ Model 720 mit 7.3 getestet und habe folgendes Ergebnis.
Das RPG-Programm ist anbei.



Loops Laufzeit in Sek
-----------------------------
10.000.000 0,52s
100.000.000 5,22s
1.000.000.000 52,53s


Um es fair zu vergleichen, habe ich die Aufgabe in C++ auf meiner IBM i geschreiben.
Hier habe ich folgendes Ergebnis



Loops Laufzeit in Sek
-----------------------------
100.000.000 1,20s
1.000.000.000 21,52s


Wichtig bei der Verarbeitungsgeschwindigkeit ist auch, ob Festkomma oder Fliesskommazahlen verwendet werden.

Wenn das Result im RPG-Programm als Festkommazahl definiert ist, dann dauert es 10x länger:

z.B. Dcl-s LocResult packed(20:2);

Lösung mit RPG


ctl-opt dftactgrp(*no) main(main);
//------------------------------------------------------------------//
// //
// Test - Performance mit PI //
// //
//----------------- //
// R.Ross 05.2020 * //
//------------------------------------------------------------------//
// Main //
//------------------------------------------------------------------//
dcl-proc main;

dcl-s LocPi float(08) inz(3.14);
dcl-s LocResult float(08);
dcl-s LocInd int(10);

for LocInd = 1 to 1000000000;
LocResult = LocInd/LocPi;
endfor;

end-proc;
//------------------------------------------------------------------//


Lösung mit C++


//------------------------------------------------------------------//
// Loop mit PI //
//------------------------------------------------------------------//

int main() {
const float PI = 3.14159265358979f;

for (int i = 0; i < 1000000000; i++) {
float result = i/PI;
}
}


Herzliche Grüße
Rainer

[xenofob]

Intel i5-8600k - Standard CPU (6 Kerne je 3,6 Ghz, keine virtuellen)
Test mit C#
1.000.000 ~ 0.005 sek (5 ms)
10.000.000 ~ 0.020 sek (20 ms)
100.000.000 ~ 0.177 sek (177 ms)
1.000.000.000 ~ 1.737 sek

569

[holgerscherer]

ich liebe Benchmarks.
Nehmen wir mal Rainers Quelle auf einer popeligen Power8 S814, 1 Core 3.06GHz. LPAR mit 0.05CPU uncapped, 4GB RAM (während da noch 8 andere LPARs laufen):

a) CRTBNDCPP PGM(QGPL/PITEST) SRCFILE(QGPL/QCPPSRC) SRCMBR(PITEST) OPTIMIZE(10)
00 20-05-05 05:55:42.549670 QWTMCEOJ QSYS 0161 *EXT
Message . . . . : Job 191390/QSECOFR/QDFTJOBD ended on 20-05-05 at 05:55:
5.985 seconds used; end code 0 .

b) CRTBNDCPP PGM(QGPL/PITEST) SRCFILE(QGPL/QCPPSRC) SRCMBR(PITEST) OPTIMIZE(40)
Message . . . . : Job 191391/QSECOFR/QDFTJOBD ended on 20-05-05 at 05:56:
.012 seconds used; end code 0 .

(Nachtrag: die Laufzeiten sind vom Programmlauf, nicht vom Compilerlauf ;-)

[Fuerchau]

Hinzu kommt noch, dass "float" nur 8-stellige Genauigkeit hat und somit von Pi nur 8 Ziffern wirken. Double wäre der richtige Typ;-), was am Ergebnis u.U. nicht wesentlich was ändert.
Außerdem weiß ich nicht, ob die Power-CPU's einen mathematischen Co-Prozessor haben wie die Intel-Chips.
Nimm auf dem PC mal decimal bzw. currency Types.

Und wieviel Einfluss hat auf der Power die MI-Schicht?
Der MI-Interpreter muss ja die Operationen für die CPU bereitstellen, was durchaus von Nachteil ist.

Auf dem PC wird nativer CPU-Code ausgeführt. Ja nach Optimierungsstufe werden Int-Variablen noch in Register geladen u.v.m.

Da auch Holgers Test die CPU nicht alleine für sich hat (weitere 8 VM's), muss man tatsächlich eher die CPU-Zeiten des Jobs als die Laufzeiten der Aktion betrachten.
Das lässt sich mit SBMJOB's auch nicht feststellen. Bei einem anderen Kunden haben wir mal gemessen, dass der Start und das Ende eines Jobs auch bereits durchaus 3-4 Sekunden CPU-Zeit gefressen haben während die Laufzeit des Programmes lediglich knapp 2 Sekunden gedauert hatte.

Alles ist eben relativ. Ich denke ein tatsächliches Ergebnis der CPU lässt sich so direkt nicht vergleichen.

Zum Vergleich:
Ein komplexer QM-Query (Recursive-CTE, Joins, derived GroupBy-Tables, ...) läuft ca. 5 Minuten.
Das Ergebnis sind ca. 150.000 Ausgabe-Zeilen und die Statusanzeige behaupted dabei ca. 1,8 Milliarden Zeilen gelesen zu haben. Ein M$-SQL-Server scheitert da kläglich.

[Rainer Ross]

dank @Holger habe ich mein C++ Programm noch etwas optimiert und was heraus kam, war wirklich überraschend.

Im ersten Schritt habe ich nur die Variablendefinition aus der Schleife genommen, das hat gleich die Laufzeit um den Faktor 5 reduziert und dann habe ich über die Compileroptionen von 10 - 40 die Zeiten gemessen. Das Ergebnis kann sich sehen lassen.



Loops Laufzeit in Sek Optimization
-----------------------------------------------
1.000.000.000 12,200s 10
1.000.000.000 8,720s 20
1.000.000.000 0,001s 30
1.000.000.000 0,001s 40






int main() {
const float PI = 3.14159265358979f;
float result = 0;

for (int i = 0; i < 1000000000; i++) {
result = i/PI;
}
}

[holgerscherer]

Im ersten Schritt habe ich nur die Variablendefinition aus der Schleife genommen, das hat gleich die Laufzeit um den Faktor 5 reduziert und dann habe ich über die Compileroptionen von 10 - 40 die Zeiten gemessen. Das Ergebnis kann sich sehen lassen.


Jeder gute Compiler erkennt, daß in der Schleife nix gemacht wird, was ausserhalb
verwendet wird. Da kann man die Schleife ja auch gleich überspringen.

Aber was sagt so ein Test schon aus - wie schnell eine CPU innerhalb des L3-Cache
springen kann? Das ist sehr synthetisch.

Viel interessanter wäre ein TPCH@300GB oder je nach Plattenplatz. Aber den macht man (wenns korrekt sein soll) nicht in 5 Minuten am Rande...
-h

[MMP400]

Der Test ist unsinnig, da auch das Rechenergebnis unsinnig ist. Da wird allenfalls getestet, wie gut der Compiler optimiert, was Rainer Ross ja auch prima gezeigt hat.